Johannes Erdfelt writes:
> On Thu, Apr 13, 2000, Richard Gooch <rgooch@ras.ucalgary.ca> wrote:
> > Johannes Erdfelt writes:
> > > devfsd is not a pretty program. It's pretty hacked together, but
> > > aside from integrating new code into it, it already knows all of the
> > > appropriate information.
> >
> > I think I take offence to that: it's got a pretty clear and simple
> > structure. What don't you like about it?
>
> Maybe the words I chose were wrong. It is not the prettiest code I've
> seen, but it's not really hacked together.
>
> I think it's biggest problem is that it's too simple. It's one
> source file. It's difficult to add things.
Agreed. That's something I've had plans for changing since last
year. I'm planning on making it far more modular and (more
importantly) able to support 3rd-party modules.
I've already got some ideas on how to do this, but they look different
from your approach. They basically go further.
> Look at the config file parsing. Some options (CLEAR_CONFIG) are
> special cased from the rest of the arguments, which don't really
> have strong argument checking.
There will inevitably be some special cases. But eventually I'd like
to have the core of devfsd just be special cases and everything else
as loadable shared objects.
> You're pretty quick to exit if something slightly goes wrong. This
> obvisously isn't all wrong.
That's a policy issue I'm somewhat open on. Bear in mind that devfsd
is still under heavy development (defined in terms of how much I
expect to change it, not how much work I've done on it recently:-).
Once it matures, a policy review will be in order.
> And the compatibility stuff is hard coded into the daemon.
Currently.
> If you look at my patch, I had to work around some issues to get things
> kinda working. Like the modprobing and stuff.
>
> There's definately room for improvement.
Indeed.
> However, this assumes you want devfsd to do more than it currently
> does. I still haven't gotten an answer from you about that.
I'm most interested in providing the essential mechanisms and an easy
way to extend it do manage specific device classes. Now that you
explained that you don't really want to extend devfs itself, I feel a
lot happier.
Anyway, if other people want to discuss devfsd, please take it to
devfs@oss.sgi.com instead. I've set the Reply-To: accordingly.
> I'd like to do lots of development on devfsd to do all of the things
> USB needs, but I'd rather not spend too much time making devfsd do
> these things, if you don't want devfsd doing it.
I'll respond to your other (private) message soon.
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.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:26 EST