Messages in this thread | | | From | (david parsons) | Subject | Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device a lloc ation) ) | Date | 8 Oct 1999 14:38:37 -0700 |
| |
In article <linux.kernel.199910081653.MAA29062@pincoya.inf.utfsm.cl>, Horst von Brand <vonbrand@inf.utfsm.cl> wrote: >orc@pell.portland.or.us (david parsons) said: >> In article <linux.kernel.19991007222450.63507@work.bitmover.com>, >> Larry McVoy <lm@bitmover.com> wrote: >> >One last comment: as far as I can tell, most people aren't against devfs, >> >they are against the current implementation. The basic idea is useful at >> >some level. If that is correct, perhaps you're all arguing about nothing >> >(not that I've ever done that; sigh). > >> Well, the best way to fix the implementation would then be to >> include it in 2.3.x and let the legion of kernel hackers fix the >> problems with it. > >Very true. The easiest way to solve _any_ problem is to have somebody else >do the solving. > >Look, the problems with devfs are of two kinds: > >- It really can't solve the problems it is supposed to solve
It solves the problems I have with the existing black magic system, which is that I want the kernel to tell me what devices it has on it.
One of the things I do with Linux is to write my own distribution. As part of this, I'm trying to build an installer that autodetects as much of the system as it can. Currently I need to jump through a lot of poorly-documented hoops to do this; for example, with a devfs numerating the number of partitions on a system is a simple case of trawling through /dev for the appropriate files, but if I don't have devfs, I get chore of running ``fdisk -l'' and picking the output apart.
Plus, for my memory detection code, I have workstations that use linux 1.2.13 through the latest development kernels. Major number creep makes it impossible to run all those kernel versions on the same machine, unless I use devfs.
>- The implementation might not be up to snuff
The implementation of many things that go into the kernel may not be up to snuff. By the time I'd tweaked my memory region allocator code to suit Linus's tastes, I'd managed to break several boundary conditions. Not too surprisingly, as soon as this code went into the development kernels the patches materialized to fix most of those problems, and people gave enough suggestions so I can fix some of the others.
If devfs was in the kernel, more fingers would be available for putting in a unionfs layer, and other enhancements (like /dev/net/eth0...ethN for people who might want to iterate through all the network devices on the machine, or /dev/pcmcia/socket0.. socketN so that pcmcia card services doesn't have to do horrible hacks to create devices in /tmp [something which bit me when I was writing the pcmcia part of my installer; pcmcia card services wanted to write into /tmp, which I had linked into the install disk so that Berkeley tar could write large scratch databases. pcmcia card services ran before that, and bombed because /tmp was pointing to never-there-was. With a devfs, card services could avoid all this handwaving.]) could be added by motivated hackers.
____ david parsons \bi/ I do tear out and replace hardware a lot. \/
- 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/
| |