Alexander Viro writes:
>
> On Tue, 13 Jun 2000, Richard Gooch wrote:
>
> > Alexander Viro writes:
> > >
> > > On Tue, 13 Jun 2000, Richard Gooch wrote:
> > > > So I don't really expect wholesale VFS changes right now (but, hey,
> > > > that doesn't seem to stop you getting stuff in;-). But that shouldn't
> > >
> > > They would not be there if not for your ability to get devfs there ;-/
> > > And took three months of piece-wise feeding the fixes into tree.
> >
> > I don't quite see what the urgency was, considering that until this
> > week, devfs has remained relatively unchanged (modulo minor VFS API
> > tweaks) in the midst of this.
>
> 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.
> > Surely you had other reasons?
>
> DAMN. OK, see here: to fix the situation with devfs (and IMNSHO
> releasing the stable branch with that situation was impossible) we
> needed to add a _lot_ of changes in infrastructure. They made sense
> and had to be done at some point anyway. Not all of them are in the
> tree, BTW. So it was a choice between removing devfs, not releasing
> 2.4 at all and doing these changes (and doing them right - otherwise
> we would just prepare a huge PITA for ourselves) ASAP. There
> _really_ had been no other options. And changing devfs proper before
> these changes are done is not too promising. Yes, some of them
> already are in there, so some stuff in devfs can be done right
> now. Good.
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.
> 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
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, writing a thesis and maintaining a
relationship, 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
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.
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.
> By the way, you do realize now why I was less than happy about devfs
> in the form it had? Because I knew what kind of work did the
> inclusion mean. And was rather pissed seeing your point-blank
> refusal to make that work less messy. Grep l-k archives - it's all
> there.
If the VFS had been better, I could have written a better devfs
implementation. But it wasn't. And people were screaming left, right
and centre for devfs to be added. Despite what the detractors think,
devfs is a very useful feature that a lot of people were hungry for.
I did the best I could with the time and infrastructure that was
available to me. I haven't refused point-blank to improve things. Now
that the VFS bindings have matured to the point where I can use them,
I've started cleaning up devfs.
And many times the things you say I find very hard to parse. That's
not a flame, BTW. I can't afford to spend a hour trying to grok one
paragraph.
> 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.
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
the world. I don't think there's any races in there, though.
BTW: have you looked at my latest devfs patch?
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
