Al, I've told you that the races will be fixed. Calm down. I know you
take a very theoretical and hard-line approach. All I said was that
the races aren't causing problems for people in real life. That's why
some vendors are using it. I never disagreed with you about the
existence of the races.
Peace, OK?
> You've been sitting on known (and easily fixable) bugs and asking to
> leave fixing them to you for what, 10 months already? Furrfu...
Yeah, 10 months during which I've gone to 7 conferences/workshops,
written 2 papers, moved house twice, took two holidays (sorry, I have
a life), moved/split/unsplit our lab network twice, caught the flu at
least once, and sundry other distractions. Pardon me for being busy.
> You are maintainer of that code. You keep insisting on having
> everything and a kitchen sink in the devfs and refuse to split the
> functionality into reasonable pieces. Essentially you are saying
> that it's all or nothing deal. Fine with me - out of these options
> I certainly prefer the latter.
The claim that splitting it into pieces will be an improvement is just
hand-waving. I've not seen a solid argument that shows how it will
help. Especially not after I remove the FS database code in devfs and
just use the dcache to store my tree. That will trim the code by 50%
or more. I'm going to wait and see how my next versions of devfs turn
out before I make any hard claims.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/