Messages in this thread | | | Subject | Re: My $0.02 on devd and devfs | From | Benny Amorsen <> | Date | 13 Oct 1999 16:43:23 +0200 |
| |
>>>>> "dp" == david parsons <orc@pell.portland.or.us> writes:
dp> ``Modern'' is not the word I'd use for the standard dp> PC-style ports on an IBM PC clone.
Then let us not redesign device handling in order to support a bus that is going away in a few years.
dp> When I load a kernel that doesn't have one of the farm of dp> parallel drivers attached, the machine recognises the parallel dp> port, but the kernel loads up blithely unaware that anything out dp> of the ordinary is done.
That is the fault of the parallel port plug and play thingy then. It should be able to recognize the attached devices. Even if that does not work for parallel ports, I cannot really consider that in itself a reason for devfs -- there is only one parallel port on most machines, with at most 3 or 4 devices attached. The current solution (static devices in an overpopulated /dev) works pretty well for parallel ports anyway.
dp> Yes, in an environment where you either (a) speculatively dp> load every possible driver to see what hardware is on the system, dp> (b) don't use modules, or (c) put autoprobing for everything under dp> the sun into the kernel.
Autoprobing IS already in the kernel for PCI, for instance. /proc/bus/pci/devices contains all the devices on the PCI bus. PCMCIA can list all connected cards without loading drivers, too. I presume USB can, but I haven't tried it. IrDA can. The only exception seems to be parallel ports.
dp> If the solution de jour to get rid of that icky devfs is dp> one of these, I'll say that the cure is much much worse than the dp> disease.
Certainly, but neither of the 3 options are needed, except for parallel ports.
Benny
- 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/
| |