Messages in this thread | | | Date | Tue, 11 May 1999 12:47:21 -0400 (EDT) | From | "Theodore Y. Ts'o" <> | Subject | Re: High speed serial ports |
| |
Date: Tue, 11 May 1999 00:23:08 +0200 From: Pavel Machek <pavel@bug.ucw.cz>
PS: tytso, is there chance for this to be included in next version? Is this still too dirty? (Well, do not look at #warning, if you say it looks good I'm sure I can find a way for it to go away...)
It's definitely a lot, a lot better. A couple of questions, though:
1) How common are these boards/chipsets. (i.e., how is it worth it to spend a lot of time making the autodetection/probe safe so it can be always enabled, or do we expect to force people to recompile the kernel in order to be able to use this feature?)
2) How safe is it to do the probing on a machine which doesn't have these boards. (i.e., Can it accidentally cause SCSI controllers to start doing low-level formats on some systems. :-)
3) Is the probing instructions timing sensitive? i.e., can we do all of this in a user-mode program, and if it succeeds in enabling the high-speed port, just simply use the standard ioctl to set the baud_base, and thus not requiring any serial driver changes at all. This has the advantage of not loading down kernel memory with one-time initialization code. It also means that all of these tables can be more easily updated, and kept separate from the kernel, which would be a good thing. It also satisfies a concern I have about what to do when the next motherboard/chipset manufacture comes along, needing to do the same thing but in a subtlely incompatible manner.... basically, this is a scaling issue.
4) If we can't do this, why not put most of hispeed.c under an __initfunc(), and simply enable all of the board to the hispeed divisor, and then set the baud_base to the appropriate value, all at boot time. Then all of this memory can be thrown away after the kernel initializes itself, and if we're sure that the probing code is safe to run on all machines, maybe we don't even need to make it a CONFIG option.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |