But as I've said, I'm not proposing that we remove device
numbers. Only that the kernel doesn't require them for it's internal
organisation (when using devfs, of course). Hence the facility in
devfs for automagic unique device number generation.
As other have said and I've agreed, unique device numbers need to
presented to userspace for POSIX. That does not mean that the best way
to organise things in the kernel is to use these device numbers.
> > Certainly the dcache does speed future accesses up
> > enormously. It's also true that millions of inodes in /dev is simply
> > unworkable.
>
> So don't do it? Use sub-directories. It isn't that big a deal.
Even with subdirectories, millions of inodes is just not an option.
> > At the very least a solution like scsidev is required.
> > However, scsidev only solves the issue of SCSI devices. USB devices
> > are another case looking for a solution.
>
> There is no reason scsidev could not be extended to handle things
> other than SCSI. I'll even volunteer to do it if required. However,
> I'm not aware of a USB driver for Linux yet and I don't see an
> awful lot of USB devices on the market yet.
I suspect if you patch the kernel to have it report all the
information needed for a device node daemon, you are approaching the
amount of patching that the devfs patch does.
USB for Linux is work in progress: that's why you haven't seen it
yet. As for it's market penetration: who knows.
> > I think that the extra layer between device nodes and device drivers
> > is an ugly hack. I see the extra level of indirection as unnecessary
> > and adding some (small, but avoidable) performance overhead.
>
> Huh???
The current major table of fops adds an extra layer of conceptual and
implementation indirection. Devfs removes that layer. This looks
cleaner to me.
Regards,
Richard....
-
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.altern.org/andrebalsa/doc/lkml-faq.html