LFS 6.1-testing issues
bdubbs at cis.sac.accd.edu
Wed Apr 13 15:32:53 PDT 2005
Bryan Kadzban wrote:
> None of your boot scripts (or your login scripts) set stty erase ^H,
> correct? You never know...
Not unless it's done in the lfs-bootscripts.
> stty seems to pull those settings in from a tcgetattr() call. The
> "struct termios" that that call fills in, has the ^H character code set
> in the c_cc[VERASE] element (this defines which keycode acts as the
> "erase" keycode).
> tcgetattr() is part of glibc.
> glibc's sysdeps/unix/sysv/linux/tcgetattr.c file defines tcgetattr() as
> a weak alias for __tcgetattr, which basically calls the TCGETS ioctl on
> the passed-in file handle.
> In the kernel, in drivers/char/tty_ioctl.c, that ioctl value translates
> real_tty->termios into a user-space version, and copies it into the
> passed-in buffer.
> real_tty's value depends on whether the tty that gets passed into the
> ioctl handler is a pseudo-terminal master, or something else. If it's a
> PTY master, then real_tty is its "link" (presumably the PTY slave,
> though I don't know that for sure). Otherwise, real_tty is the
> tty_struct that was passed in. (This is all happening in
> drivers/char/tty_ioctl.c, function n_tty_ioctl.)
> Beyond that, I get lost in the kernel. I *think* the tty_struct that
> gets passed in depends on the line discipline (I can't find any
> promising callers of n_tty_ioctl, and the only other promising reference
> to it is the spot that sets it as the ioctl handler for the N_TTY line
> discipline, which seems to be the "standard" TTY line discipline). I
> also know that ->termios has to be initialized somewhere (when the line
> discipline is opened? doesn't seem to be it though), but I can't figure
> out where.
Wow. Nice analysis. It suggests something else. When I compiled the
kernel, I turned off Legacy (BSD) PTY support. I'll build another kernel
and add that back and see if that makes a difference.
> Did you say you were using some kind of framebuffer console? Does it
> help at all if you change that, or did you try that already?
No. I do use vga=0x0f07 on the kernel line, but that shouldn't affect input.
More information about the lfs-dev