linux终端backspace不能删除字符的解决方案

在linux/unix 平台的经常使用scanf从键盘获取字符，输出字符后按Backspace键删除时，会出现^H，这对习惯了按Backspace键删除的用户来说，感觉非常别扭，虽然可以通过Ctrl+Backspace组合键实现删除功能可通过stty命令修改终端配置来实现Backspace删除功能。如下：

　　QUOTE:

　　[oracle@RHEL5 ~]$ id

　　uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),503(asadmin)

　　[oracle@RHEL5 ~]$ stty erase ^h

　　若要恢复Ctrl+Backspace组合键删除功能，可执行以下命令：

　　QUOTE:

　　[oracle@RHEL5 ~]$ id

　　uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),503(asadmin) [oracle@RHEL5 ~]$ stty erase ^?

　　同时可通过stty -a查看所有的终端设置：

　　QUOTE:

　　oracle||oralinux||/home/oracle||-->>id

　　uid=500(oracle) gid=501(oinstall) groups=500(dba),501(oinstall)

　　oracle||oralinux||/home/oracle||-->>stty -a

　　speed 38400 baud; rows 24; columns 80; line = 0;

　　intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>;

　　eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;

　　lnext = ^V; flush = ^O; min = 1; time = 0;

　　-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts

　　-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff

　　-iuclc -ixany -imaxbel

　　opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0

　　isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt

　　echoctl echoke

　　 清单 2. 主要结构

　　struct scsi_cmnd {

　　……

　　void (*done) (struct scsi_cmnd *); /* Mid-level done function */

　　……

　　int retries; /*retried time*/

　　int timeout_per_command; /*timeout define*/

　　……

　　enum dma_data_direction sc_data_direction; /*data transfer direction*/

　　……

　　unsigned char cmnd[MAX_COMMAND_SIZE]; /*cdb*/

　　void *request_buffer; /* Actual requested buffer */

　　struct request *request; /* The command we are working on */

　　……

　　unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE];

　　/* obtained by REQUEST SENSE when

　　* CHECK CONDITION is received on original

　　* command (auto-sense) */

　　/* Low-level done function - can be used by */

　　/*low-level driver to point  to completion function. */

　　void (*scsi_done) (struct scsi_cmnd *);

　　……

　　};

　　初始化的过程首先按照电梯调度算法，从块设备的请求队列上取出一个块访问请求，根据块访问请求的信息，定义 SCSI 命令中数据传输的方向，长度和地址。其次，定义 CDB，SCSI 中间层的回调函数等。

　　在完成初始化后，SCSI 中间层通过调用scsi_host_template[5]结构中定义的queuecommand函数将 SCSI 命令提交给 SCSI 底层驱动部分。queuecommand函数，是一个 SCSI 命令队列处理函数，在 SCSI 底层驱动中，定义了queuecommand函数的具体实现。因此，SCSI 中间层，调用queuecommand函数实际上就是调用了底层驱动定义的queuecommand函数的处理实体，将 SCSI 命令提交给了各个厂家定义的 SCSI 底层驱动进行处理。这个过程和通用块设备层调用 SCSI 中间层的处理函数进行块请求处理的机制很相似，这也体现了 LINUX 内核代码具有很好的扩展性。底层驱动接受到请求后，就要开始处理 SCSI 命令了，这一层和硬件关系紧密，所以这块代码一般都是由各个厂家自己实现。基本流程可概括为：从底层驱动维护的队列中，取出一个 SCSI 命令，封装成厂家自定义的请求格式，然后采用 DMA 或者其他方式，将请求提交给 SCSI TARGET 端，由 SCSI TARGET 端对请求处理，并返回执行结果给 SCSI 底层驱动层。

　　SCSI命令执行结果的处理

　　当 SCSI 底层驱动接受到 SCSI TARGET 端返回的命令执行结果后，SCSI 子系统主要通过两次回调过程完成对命令执行结果的处理。 SCSI 底层驱动在接受到 SCSI TARGET 端返回的命令执行结果后，会调用 SCSI 中间层定义的回调函数，将处理结果交付给 SCSI 中间层进行处理，这是第一次回调过程。 SCSI 中间层处理完成后，将调用 SCSI 上层定义的回调函数，结束 IO 在整个 SCSI 子系统中的处理，这为第二次回调过程。

　　第一次回调：

　　SCSI 中间层在调用queuecommand函数将 SCSI 命令提交给 SCSI 底层驱动的同时，也将回调函数指针传给了 SCSI 底层驱动。底层驱动接受到 SCSI TARGET 端返回的命令执行结果后，会调用该回调函数，产生一个中断号为 BLOCK_SOFTIRQ 的软中断进行第一次回调处理。在这次回调处理过程中，SCSI 中间层首先会根据 SCSI 底层驱动处理的结果判断请求处理是否成功。处理成功，并不意味着处理没有错误，而是返回的信息，能够让 SCSI 中间层很明确的知道，对于这个命令，中间层已经没有必要继续进行处理了。所以，对于处理成功的 SCSI 命令，SCSI 中间层会调用第二次回调函数进入到第二次回调过程。清单 3 显示了 SCSI 中间层定义的该软中断的处理函数。

　　清单 3. 该软中断的处理函数

　　static void scsi_softirq_done(struct request *rq)

　　{

　　……

　　disposition = scsi_decide_disposition(cmd);

　　……

　　switch (disposition) {

　　case SUCCESS:

　　scsi_finish_command(cmd);

　　//enter to second callback process

　　break;

　　case NEEDS_RETRY:

　　scsi_retry_command(cmd);

　　break;

　　case ADD_TO_MLQUEUE:

　　scsi_queue_insert(cmd, SCSI_MLQUEUE_DEVICE_BUSY);

　　break;

　　default:

　　if (!scsi_eh_scmd_add(cmd, 0))

　　scsi_finish_command(cmd);

　　}

　　}

　　第二次回调：

　　不同的 SCSI 上层模块会定义自己不同的第二次回调函数，如 SD 模块，会在sd_init_command函数中，定义自己的第二次回调函数sd_rw_intr，这个回调函数会根据 SD 模块的需要，对 SCSI 命令执行的结果做进一步的处理。清单 4 显示了 SD 模块注册第二次回调的代码。虽然各个 SCSI 上层模块可以定义自己的第二次回调函数，但是这些回调函数最终都会结束 SCSI 子系统对这个块访问请求的处理。

　　清单 4. SD 模块注册第二次回调的代码

　　static int sd_init_command(struct scsi_cmnd * SCpnt)

　　{

　　……

　　SCpnt->done = sd_rw_intr;

　　return 1;

　　}

　　SCSI子系统的错误处理

　　由于 SCSI 底层驱动是由厂商自己实现的，在此就不予讨论。除此之外，SCSI 子系统的出错处理，主要是由 SCSI 中间层完成。在第一次回调过程中，SCSI 底层驱动将 SCSI 命令的处理结果以及获取的 SCSI 状态信息返回给 SCSI 中间层，SCSI 中间层先对 SCSI 底层驱动返回的 SCSI 命令执行的结果进行判断，若无法得到明确的结论，则对 SCSI 底层驱动返回的 SCSI 状态、感测数据等进行判断。对于判断结论为处理成功的 SCSI 命令，SCSI 中间层会直接进行第二次回调；对于判断结论为需要重试的命令，则会被加入块设备请求对列，重新被处理。这个过程可称为 SCSI 中间层对 SCSI 命令执行结果的基本判断方法。

　　一切看起来似乎是这么简单，但是实际上并非如此，有些错误是没有明确的判断依据的，如感测数据错误或 TIMEOUT 错误。为了解决这个问题，LINUX 内核中 SCSI 子系统引入了一个专门进行错误处理的线程，对于无法判断错误原因的 SCSI 命令，都会交由该线程进行处理。线程处理过程和两个队列密切相关，一个是错误处理队列（eh_work_q），一个是错误处理完成队列 (done_q) 。错误处理队列记录了需要进行错误处理的 SCSI 命令，错误处理完成队列记录了在错误处理过程中被处理完成的 SCSI 命令。清单 5 显示了线程对错误处理队列上记录的命令进行错误处理的过程。

　　清单 5. 错误处理的过程

　　scsi_unjam_host{

　　……

　　if (!scsi_eh_get_sense(&eh_work_q, &eh_done_q))

　　//get sense data

　　if (!scsi_eh_abort_cmds(&eh_work_q, &eh_done_q))

　　//abort command

　　scsi_eh_ready_devs(shost, &eh_work_q, &eh_done_q);

　　//reset

　　scsi_eh_flush_done_q(&eh_done_q);

　　//complete error io on done_q

　　……

　　}

　　整个处理过程可归纳为四个阶段：

　　感测数据查询阶段

　　通过查询感测数据，为处理 SCSI 命令重新提供判断依据，并按照前述基本判断方法进行判断。如果判断结果为成功或者重试，则可将该命令从错误处理队列移到错误处理完成队列。若判断失败，则命令将会继续保留在 SCSI 错误处理队列中，错误处理进入到 ABORT 阶段。

　　ABORT阶段

　　在这个阶段中，错误处理队列上的 SCSI 命令会被主动 ABORT 掉。被 ABORT 的命令，会被加入到错误处理完成队列。若 ABORT 过程结束，错误处理队列上还存在未能被处理的命令，则需进入 START STOP UNIT 阶段进行处理。

　　START STOP UNIT阶段

　　在这个阶段，START STOP UNIT[6] 命令会被发送到与错误处理队列上的命令相关的 SCSI DEVICE 上，去试图恢复 SCSI DEVICE，如果在 START STOP UNIT 阶段结束后，依旧有命令在错误处理队列上，则需要进入 RESET 阶段进行处理。

　　RESET阶段

　　RESET 阶段的处理过程分三个层次：DEVICE RESET，BUS RESET 和 HOST RESET 。首先对与错误队列上的命令相关的 SCSI DEVICE，进行 RESET 操作，如果 DEVICE RESET 后，SCSI 设备能处于正常状态，则和该设备相关的错误处理队列上的错误命令，会被加入到错误处理完成队列中。若通过 DEVICE RESET 不能处理所有的错误命令，则需进入到 BUS RESET 阶段，BUS RESET 会对与错误处理队列上的命令相关的 BUS，进行 RESET 操作。若 BUS RESET 还不能成功处理所有错误处理队列上的 SCSI 命令，则会进入到 HOST RESET 阶段，HOST RESET 会对与错误处理队列上的命令相关的 HOST 进行 RESET 操作。当然，很有可能 HOST RESET 也不能成功处理所有错误命令，则只能认为错误处理队列上错误命令相关的 SCSI 设备不能被使用了。这些不能被使用的设备会被标记为不能使用状态，同时相关的错误命令都会被加入到错误处理完成队列中。

　　对于被加入到错误处理完成队列上的请求，若是在设备状态正确，命令重试次数小于允许次数的情况下，这些命令将被重新加入到块访问请求队列中，进行重新处理；否则，直接进行第二次回调处理，完成 SCSI 子系统对块访问请求的处理。这样，SCSI 子系统就完成了 SCSI 命令错误处理的整个过程。

　　结束语

　　本文浅析了 SCSI 子系统中的 IO 处理机制，希望对大家理解 SCSI 子系统和块设备驱动能有所帮助。