Alexander Viro writes:
>
>
> 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.
;-)
> > 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.
Well, I'm certainly happy to see the VFS binding stuff (even down to
the file/device level) have gone in. Good job.
> > > 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?
Unfortunately procmail doesn't support the following syntax:
* CONTENT_just_another_rant_against_devfs
so it makes it hard to distinguish between bug reports, feature
requests, *new* technical criticisms or alternative suggestions, and
just repeat flaming.
> > 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.
Actually, I've seen one or two gripes about recent VFS changes, so
there's always someone who will complain. But it's been my experience
that arguments about bloat don't always correlate strongly with
reality.
And I do know that if *I* had done those VFS changes (with the obvious
intent of making devfs itself smaller), then the screams of bloat
would have spurt forth. Guilt by association and all that.
> > > 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.
Let me check I understand what you mean. You're concerned about the
way I *invalidate*, rather than the way I *revalidate*?
So, basically, the order in which I unregister devices and invalidate
dentries is where you see a problem?
You're not saying there is a problem with the way I do revalidates?
> > BTW: have you looked at my latest devfs patch?
>
> Looking at it.
Thanks.
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
