Messages in this thread | | | Date | Sat, 09 Oct 1999 18:34:30 +0200 | From | Martin Dalecki <> | Subject | Re: [linux-usb] Re: USB device allocation |
| |
Alexander Viro wrote: > > On Sat, 9 Oct 1999, Khimenko Victor wrote: > > > In <Pine.GSO.4.10.9910090525450.14121-100000@weyl.math.psu.edu> Alexander Viro (viro@math.psu.edu) wrote: > > > > > > AV> On Sat, 9 Oct 1999, Khimenko Victor wrote: > > > > >> AV> Learn. This place is not exactly UNIX 101, you know... > > >> > > >> Yes. I know. I know even more: Linux is NOT Unix. > > > > AV> Yes, it is. Sorry to break it upon you, but.. > > > > 1. It's NOT certified as Unix. > > 2. It's NOT derived from Unix sources. > > And it shares helluva lot of basic design. Which is all that matter when > you are working with it. You are not hacking or using the certificate. > > > Hmm. I think. Think once more. Directory was text file initially and was > > modified by suid mkdir program when needed. It's changed now. Why ? It was > > No, it wasn't. Directories were different kind of inodes from the very > beginning. > > > so wonderfull idea ! /dev is not filesystem now but bunch of special files. > > Why to have special files and not special filesystem is so wonderfull idea ? > > Sigh... > a) special filesystem might be nice, but not with the _current_ > _devfs_ _design_. > b) our VFS is not well-suited for mounting the same fs in several > places. It can be kludged with revalidate and friends but it means races. > Yes, procfs is not better. > > > AV> One more time. Slowly. Take. Care. To. Look. At. The. Code. That. Is. > > AV> Supposed. To. Work. With. Devfs. Look. At. The. VFS. Code. > > AV> Sheesh... > > > > You mean that the only reason to reject devfs is troubles with VFS ? > > Damn!!! One. More. Fscking. Time. I'm talking about _my_ problems with > devfs. I'm not a telepath. I don't have a habit of speaking for other > folks. _MY_ (moi, b...) problems with devfs are VFS-related. > > > AV> Though luck, then. What you are telling boils down to: "I want it; I don't > > AV> give a damn for the problems; code around and I can't be even bothered to > > AV> figure out what those problems _are_." Do you really expect to be taken > > AV> seriously? > > > > Problems are solved by Richard mostly. So far I hear only about one technical > > problem with devfs (from you BTW): problems with VFS (which one BTW: rename is > > not implemented in procfs and procfs is included in kernel; what's is so > > different in devfs?). This is THE ONLY REAL problem. > > Boga-dushu-mat'! No, it is not the only real problem. Just from the quick > look at the latest patch: there is an interesting race between lookup and > unregistering an intermediate directory. _Lack_ of rename() kinda sucks, > but it's not a VFS problem per se. But races between the operations on > different instances of devfs (mounted several times) _are_. And we don't > have any protection other than the big lock here - i_sem doesn't help > here. AFAICS the same applies to a bunch of sweet races between lookup() > and (e.g.) rmdir() (in the moment of blocking revalidate on dentry). > > > BTW what about devpts and procfs: are they any better from VFS side ? They are > > both in kernel and devpts was added when devfs already existed... > > devpts is definitely better. procfs ;-/ Kinda-sorta. proc_unregister() > sucks hard and the fact that calls are scattered over the crapload of > drivers doesn't make life easier. Sigh... > > > AV> No, sir. You will have to deal with the technical reasons. "Purely" has > > AV> nothing to this sad fact. BTW, may I also remind you that l-k is a > > AV> _technical_ list? > > > > Hmm. Looking on messages published there for last few days you hardly can say > > that :-) If the only reasons to not include devfs in kernel are technical ones > > then what are they ? If there are some reasons then WHERE should are they be > > discussed ? For devfs to be included in kernel ALL reasons should be > > resolved... > > Yup. As for the good places for discussing that stuff - heck, Richard is > more than welcome to fsdevel. _If_ devfs is going to go into the standard > tree at all it will not happen in one huge gulp. Patch is too big and > affects too many places. Both devfs and the standard tree have problems > and I'm more than sure that Richard will not object to getting the patch > smaller. > > [snip] > > has it AFAIK. Why it's Ok for procfs and not Ok for devfs ? > Procfs sucks. It's a PITA and will remain such for quite a while, > I'm afraid. It got into the kernel and too many utilities depend on its > current form to fix it fast. Worse yet, it doesn't have a coherent > interface and calls are scattered all over the tree + 3rd-party drivers. > Heck, that's one of the reasons why additional interfaces are not too > welcome, to put it mildly. They tend to stick. If they are local enough > they can be fixed later, but otherwise they'ld bloody better be good from > the very beginning _and_ remain so.
Thank's! Finally a single only developer on linux-kernel who has enough of guts to admit to design errors here in a crear nonnebulous way :-).
--Marcin
- 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/
| |