Interesting . . hadn't thought about that. I can't help but wonder if
this wouldn't make more sense as a plan for transition to devfs. Little
setup from the user end. From the device end, look first to /devfs then
fall back to /dev Provides time to transition code,scripts,etc to the new
way of doing things. Maybe this needs to be suggested further up the food
chain ;-) My objections are simply one of setup time and time spent
fixing whatever breaks while I learn how it works.
Keith
On Sun, 7 May 2000, Greg KH wrote:
> <nice commentary on why Keith isn't using devfs and isn't going to for a
> while snipped>
>
> Ok, All of this devfs commentary has finally driven me to comment on
> this.
>
> Why not just run devfs AND old style /dev at the same time? That's what
> I'm doing, and have been doing for over a month. devfs is mounted at
> /devfs and /dev is the normal stuff.
>
> This way I get the benefits of /devfs when I want it (basically only for
> testing out usb devfs support lately) and I don't have to modify any of
> my system scripts. I've modified all of my usb-serial scripts to use
> /devfs and will slowly be moving other system scripts to devfs also.
>
> And for those who don't want to do that, there is the devfsd daemon that
> models the "old" /dev nodes on top of devfs.
>
> Relatively painless way of using devfs and getting the benefits of it,
> while not worrying about the rest of your system.
>
> And if the usb userspace stuff relies on devfs, fine, it will run on my
> boxes then.
>
> I don't want to get into why some people don't want to use devfs, or the
> side effects of it, just wanted to say how I am handling the system on
> my networks.
>
> Just my two cents,
>
> greg k-h
> greg@(kroah|wirex).com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
