> C. Scott Ananian writes:
> > Why not support old-style device nodes as backwards-compatibility
> > barnacles *even for* drivers converted to use devfs? That way we have the
> > benefits of both the old (simple chroot jails) and new (more flexible
> > device naming, etc) systems? Why break stuff we don't have to?
>
> Well, one thing that may prevent that is if adding devfs support to
> some drivers and maintaining backward compatibility in the same kernel
> image is messy to do. I dunno.
Well, the old-style device node support is already present, no?
Admittedly, I haven't hacked this part of the kernel, but it's just a list
of structures indexed my major/minor device numbers, no?
> Another reason is that during development it may be handy to be able
> to umount /devfs and see what breaks. I've already found one bug that
> way.
Bug-fixing code should be #ifdef'ed (or #ifndef'ed) with #defines *in the
source code* for other similarly inclined bug-hunters. It's not a valid
reason to remove features the rest of us might find useful.
> However, if there isn't a problem with having devfs support and
> major&minor support for a driver *at the same time*, then I'll allow
> it and use a config option (I still want to be able to disable support
> for major&minors).
Why? How does the (entirely separate) major/minor list conflict with
devfs? If it's for bug-hunting reasons, feel free to #ifdef it, but it
shouldn't be a *config* option. Bug-tracking traditionally goes in the
source files, so poor saps who just want to configure and compile don't
have to bother with it.
--Scott
@ @
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-oOO-(_)-OOo-=-=-=-=-=
C. Scott Ananian: cananian@lcs.mit.edu / Declare the Truth boldly and
Laboratory for Computer Science/Crypto / without hindrance.
Massachusetts Institute of Technology /META-PARRESIAS AKOLUTOS:Acts 28:31
-.-. .-.. .. ..-. ..-. --- .-. -.. ... -.-. --- - - .- -. .- -. .. .- -.
PGP key available via finger and from http://www.pdos.lcs.mit.edu/~cananian