From: Richard Gooch <rgooch@ras.ucalgary.ca>
To: Alexander Viro <viro@math.psu.edu>
Cc: Rene Rebe <rene.rebe@gmx.net>,
greg@kroah.com, jonathan@daria.co.uk,
linux-kernel@vger.kernel.org
Subject: Re: Q: device(file) permissions for USB
Date: Thu, 6 Dec 2001 17:21:44 -0700 [thread overview]
Message-ID: <200112070021.fB70Lik02148@vindaloo.ras.ucalgary.ca> (raw)
In-Reply-To: <Pine.GSO.4.21.0112061903230.29985-100000@binet.math.psu.edu>
In-Reply-To: <20011207005707.6a09706a.rene.rebe@gmx.net> <Pine.GSO.4.21.0112061903230.29985-100000@binet.math.psu.edu>
Alexander Viro writes:
>
>
> On Fri, 7 Dec 2001, Rene Rebe wrote:
>
> > > > usbdevfs does not require devfs, which enables the majority of Linux
> > > > users to actually use it.
> > >
> > > s/majority of/& sane/
> >
> > Writing bash scripts is easier than adding two lines to devfsd.conf?? Btw.
> > sane users do not use such a mahor/messy distro ...
>
> Sane users don't run stuff with known unfixable security holes. The
> only variant that has any promise to get that crap fixed got no
> testing to speak about.
I gave it as much testing as I could, but there comes a point where
you don't get any more test reports (because people are lazy) where
you have to throw it out for a pre-patch which *will* get testing.
I got tired of begging for people to test it.
Basic chicken and egg problem. It's the same reason Linus released
2.4.0-test* when it was really 2.3.99++.
> Ask Richard if you don't believe me - or grep the l-k archives.
> Again, all variants of devfs up to and including 2.4.16 are
> unfixable according to devfs author.
It's a matter of degree. I did fix it, by putting locking and
refcounting in. Is that a re-write or a fix? It's a grey area. I've
been calling it a re-write, but you could also argue that it's "fix".
My main claim is that the old core wasn't amenable to fixing with a
few tweaks here and there.
Anyway, this is all semantics and history. All that matters is that
the latest code is much better, and I'm working on getting the last
wrinkles out. We're still in a pre-patch, so no need to panic yet.
I've been diligent about fixing things (mostly battling with
incomplete bug reports).
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
next prev parent reply other threads:[~2001-12-07 0:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.ljcupnv.1ghotjk@ifi.uio.no>
2001-12-06 20:14 ` Jonathan Hudson
2001-12-06 21:30 ` Rene Rebe
2001-12-06 23:27 ` Greg KH
2001-12-06 23:37 ` Alexander Viro
2001-12-06 23:57 ` Rene Rebe
2001-12-07 0:09 ` Alexander Viro
2001-12-07 0:35 ` Rene Rebe
2001-12-07 0:20 ` Rene Rebe
2001-12-07 0:21 ` Richard Gooch [this message]
2001-12-06 23:45 ` Rene Rebe
2001-12-07 0:00 ` Greg KH
2001-12-07 0:11 ` Rene Rebe
2001-12-07 0:21 ` Greg KH
2001-12-06 20:01 kees
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200112070021.fB70Lik02148@vindaloo.ras.ucalgary.ca \
--to=rgooch@ras.ucalgary.ca \
--cc=greg@kroah.com \
--cc=jonathan@daria.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rene.rebe@gmx.net \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®