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/