On Tue, 13 Jun 2000, Richard Gooch wrote:
> > Yes. And all that time mounting the thing at several point was a huge,
> > fscking hole.
>
> Sure. And hence RedHat wasn't going to compile it in.
Fine with RedHat, but how in hell does it solve the problem? I don't
_CARE_ for any "party line". I don't belong to any fucking parties, no
matter where I'm employed. Excuse me, but I had seen enough of that shit
in .su and .ru and that's a game I don't play.
[snip]
> OK, but since you never liked devfs in the first place, I'm surprised
> you would care so much about devfs races. I'd just expect a "don't use
> devfs" response, rather than all this effort to help clean up devfs.
If it is a part of ftp.kernel.org tree and I don't want to fork - too
fscking bad, that's part of the things I'm dealing with.
> > What we are paying no is the price of these years when devfs grew
> > larger and larger and accumulated stuff from all layers of VFS. All
> > these changes were not done - you were just sitting on the growing
> > patch and refused to turn it into the set of small patches, each
> > doing one thing and doing it right. Fine, so that work has to be
> > done now. I think that I'm actually getting it quite fine - 3-4
> > months and most of the infrastructure is built, thank you very much.
>
> Try to imagine the shit I've been going through the last 2.5 years
> with devfs. Flamewar after bloody flamewar (*NOT* about minor things
.procmailrc?
> like devfs races, the merits of devfs multi-mounting vs. VFS bindings,
> but basic arguments about the very concept). Between the flamewars,
> tracking constant kernel drift,
[check]
> writing a thesis
[check]
> and maintaining a
> relationship,
[check]
> I'm surprised I got as much done on it as I did. On top
> of that, when I finally had more time available, Linus dropped the
> whole namespace change thing on me.
> Besides, if I were to have tried to clean up the VFS first, I expect I
> would have encountered extreme opposition, as people would have used
> it as another reason to oppose devfs ("don't bloat the VFS"). And
So don't bloat it ;-) If you will compare the size before and after you'll
see that no bloat went in.
> people would oppose the VFS changes because they'd want another
> obstacle for devfs. No thanks. I wasn't going to get into that fight.
>
> Also, trying to maintain multiple dependent patches is a lot of work.
[check]
> Roll on BK.
>
> > Yes, I had other reasons. This kind of stuff actually has to be done
> > right or not at all. So these changes started they had pulled in
> > quite a bit of other stuff - handling of pseudoroots in binary
> > emulation, for example. But doing all that stuff during the freeze
> > and in effect postponing the release... Not if we had any
> > choice. Unfortunately, we hadn't.
>
> There's always a choice. You could always have opted for the RedHat
> party line: don't use devfs because it's racy.
I don't opt for party lines of any description. Besides, it's not a RH
release I'm talking about. Linux != RH.
> > And stuff already in the tree is not enough - aside of multiple
> > mounts there is revalidate() problems. So it will take more...
>
> IIRC, your concerns here were that devfs "knew" about how revalidates
> work, and thus if you want to change the VFS, devfs will have to track
> that.
Not only that, actually - order of invalidation was incorrect, IIRC.
> I'll agree that's not ideal, but given the amount of dependence other
> filesystems have on VFS subtleties, I don't see why it's the end of
Most of them actually has very few dependencies - there are exceptions
(HFS, UMSDOS, autofs), but majority is pretty clean in that respect.
> the world. I don't think there's any races in there, though.
Famous last words.
> BTW: have you looked at my latest devfs patch?
Looking at it.
