lkml.org 
[lkml]   [2002]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectdriverfs: driver interface


greg@kroah.com wrote:

>
>But a PCI bus could also be present, with a USB controller, and the hid
>driver would be able to handle devices on it too. So how would you show
>this "dual" relationship then?
>
Good point.

Check this out. Rather than explaining it, I've attached it to this
email. It might solve this problem. It's based on an idea I stated
earlier. I haven't quite worked out the details yet and I'm not really
even sure if it's the best thing to do. I created a sample interface
comprised of folders and links and then tarred and gzipped it. I'm
looking forward to some reactions on it. (look in ./driver)

Also I have two questions:

1.) Is it worth it to remove the bus interface?
my answer: I think it is because an interface in which drivers can
have children is far more flexable and scaleable. Also it would result
in less code. I'm looking for some feedback so I can revise my current
efforts.

2.) Should driver management occur through driver model interfaces?
my answer: I already have the code to do this, it's just a matter of
what's the best way to manage drivers. I feel that the driver model is
the best place because it offers the most flexability and it allows for
control over all drivers, not just modules.

Thanks,
Adam

PS: I'm currently working on a patch that just implements the read for
"driver" as discussed earlier.

[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.098 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site