Message-ID: <3D61104E.7050002@netscape.net>
Date: Mon, 19 Aug 2002 15:35:42 +0000
From: Adam Belay <ambx1@netscape.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
MIME-Version: 1.0
To: mochel@osdl.org
CC: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5.31 driverfs: patch for your consideration
References: <Pine.LNX.4.44.0208191103160.1048-100000@cherise.pdx.osdl.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2108
Lines: 53


mochel@osdl.org wrote:

>
>patch -l does not imply cleanly. That will ignore the whitespace munging 
>that your MUA is doing. 
>
You're right it's incorrect to say cleanly

>>also I was wondering if you think resource management variables (irq,
>>io, dma, etc) should live in the device structure like power management
>>variables do?  Global resource management seams interesting to me,
>>although there already is a proc interface that does list resources, I'm
>>wondering if the driver model is a good place to put such an interface?
>>
>
>Yes. We talked about doing that from the very beginning, and were going to 
>see how things worked out. There was some discussion about this at OLS, 
>too. But, I'm not sure it's ready for it yet.
>
That's great, I think there's a big advantage doing this because if this 
data lies in the driver model code then it's very easy to standardize 
interfaces for hardware and power management

>
>
>What would be nice would be some way to cleanly represent conditional 
>attributes of devices, like resource and power management. I think I 
>almost have something with the device interface stuff, but I fear it's a 
>fine line to cross over into Abstraction Hell... 
>
Could you please send me a patch, if there is one, concerning your work 
with conditional attributes, I'd love to take a look.  If we could work 
something out like this it would solve all kinds of problems.  I'll look 
into it.  Remember that devfs patch I had a while ago.  Instead of using 
devfs handles I could use kdev_t and export the major and minor through 
a conditional attribute.  If so should a list of major and minor pairs 
be in one file?


Also when you say conditional attributes do you mean conditional in the 
device structure as well.  In other words do you mean a list or hash of 
attributes in the device structure?

Thanks,
Adam

-
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/