Yes. There probably isn't a problem. I have yet to look into it.
> > 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.
What I say "see what breaks", I'm thinking of the sysadmin testing to
see if they have set things up properly.
> > 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.
You may want to disable major&minor support for devfs-capable drivers
so that you *know* that you are using devfs.
Anyway, I've just added a new config option CONFIG_DEVFS_ONLY which is
off by default, so you will have support for both.
Regards,
Richard....