On Sat, May 26, 2007 at 12:12:02PM -0400, Bill Davidsen wrote:
> Greg KH wrote:
> > On Wed, May 23, 2007 at 09:27:12AM -0400, Mark Lord wrote:
> >> Greg KH wrote:
> >>> And yes, it only starts to look for things when it recieves an event, it
> >>> does not "scan" sysfs at all.
> >> Does it "look
Greg KH wrote:
On Wed, May 23, 2007 at 09:27:12AM -0400, Mark Lord wrote:
Greg KH wrote:
And yes, it only starts to look for things when it recieves an event, it
does not "scan" sysfs at all.
Does it "look for" only that one event, or does it "scan" at that point?
udev will act on that eve
On Wed, May 23, 2007 at 09:27:12AM -0400, Mark Lord wrote:
> Greg KH wrote:
> > And yes, it only starts to look for things when it recieves an event, it
> > does not "scan" sysfs at all.
>
> Does it "look for" only that one event, or does it "scan" at that point?
udev will act on that event, an
Greg KH wrote:
And yes, it only starts to look for things when it recieves an event, it
does not "scan" sysfs at all.
Does it "look for" only that one event, or does it "scan" at that point?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
Greg KH wrote:
> If you can come up with a wrapper that will work, please let me know and
> I'll be glad to add it. Right now, it's pretty darn simple to do this
> (look at the USB and PCI core code for examples if you need it.)
>
>
I guess we have different views on "simple" :)
I had a look
On Tue, May 22, 2007 at 10:38:57AM +0200, Cornelia Huck wrote:
> On Mon, 21 May 2007 21:28:15 +0200,
> Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> > We could change the driver-core to suppress the creation of an attribute
> > if the attribute's show() or store() method returns something like
> > -E
On Tue, May 22, 2007 at 05:40:50PM +0200, Pierre Ossman wrote:
> Kay Sievers wrote:
> > We could change the driver-core to suppress the creation of an attribute
> > if the attribute's show() or store() method returns something like
> > -ENOENT at registration time?
> > The driver would pass _all_ p
On Tue, May 22, 2007 at 10:43:55PM -0400, Dmitry Torokhov wrote:
> On Tuesday 22 May 2007 17:24, Mark Lord wrote:
> > Dmitry Torokhov wrote:
> > > 1. dev->uevent_suppress = 1;
> > > 2. device_register(dev);
> > > 3. device_create_file(dev, ...);
> > > 4. dev->uevent_suppress = 0;
> > > 5. kobject_u
On Tuesday 22 May 2007 17:24, Mark Lord wrote:
> Dmitry Torokhov wrote:
> > 1. dev->uevent_suppress = 1;
> > 2. device_register(dev);
> > 3. device_create_file(dev, ...);
> > 4. dev->uevent_suppress = 0;
> > 5. kobject_uevent(&dev->kobj, KOBJ_ADD);
>
> I don't see how that prevents an already-runn
Pierre Ossman wrote:
Kay Sievers wrote:
We could change the driver-core to suppress the creation of an attribute
if the attribute's show() or store() method returns something like
-ENOENT at registration time?
The driver would pass _all_ possible attributes of the device at
registration time, bu
Dmitry Torokhov wrote:
On Sunday 20 May 2007 07:01, Pierre Ossman wrote:
Hi Greg,
I'm reworking the sysfs stuff in the MMC layer to be a bit more flexible, but
there is one thing that has me baffled; how do you add attributes to an object
in a race free manner when you have a dynamic set of att
On 5/22/07, Pierre Ossman <[EMAIL PROTECTED]> wrote:
Kay Sievers wrote:
> We could change the driver-core to suppress the creation of an attribute
> if the attribute's show() or store() method returns something like
> -ENOENT at registration time?
> The driver would pass _all_ possible attributes
Kay Sievers wrote:
> We could change the driver-core to suppress the creation of an attribute
> if the attribute's show() or store() method returns something like
> -ENOENT at registration time?
> The driver would pass _all_ possible attributes of the device at
> registration time, but the core wou
On Mon, 21 May 2007 21:28:15 +0200,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> We could change the driver-core to suppress the creation of an attribute
> if the attribute's show() or store() method returns something like
> -ENOENT at registration time?
> The driver would pass _all_ possible attribut
On Mon, 2007-05-21 at 20:43 +0200, Pierre Ossman wrote:
> Kay Sievers wrote:
> >
> > Do you have a fixed set of attribute names, where you just want to
> > create a subset from that matches the individual device, or do you
> > need some sort of free naming for the attributes?
>
> Currently, the na
Kay Sievers wrote:
>
> Do you have a fixed set of attribute names, where you just want to
> create a subset from that matches the individual device, or do you
> need some sort of free naming for the attributes?
>
Currently, the names are fixed (and I don't see any pressing need for
having dynamic
On 5/20/07, Pierre Ossman <[EMAIL PROTECTED]> wrote:
I'm reworking the sysfs stuff in the MMC layer to be a bit more flexible, but
there is one thing that has me baffled; how do you add attributes to an object
in a race free manner when you have a dynamic set of attributes.
I've looked at other
Dmitry Torokhov wrote:
> 1. dev->uevent_suppress = 1;
> 2. device_register(dev);
> 3. device_create_file(dev, ...);
> 4. dev->uevent_suppress = 0;
> 5. kobject_uevent(&dev->kobj, KOBJ_ADD);
>
>
Simple enough. Thanks :)
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www
On Sunday 20 May 2007 07:01, Pierre Ossman wrote:
> Hi Greg,
>
> I'm reworking the sysfs stuff in the MMC layer to be a bit more flexible, but
> there is one thing that has me baffled; how do you add attributes to an object
> in a race free manner when you have a dynamic set of attributes.
>
> I'
Hi Greg,
I'm reworking the sysfs stuff in the MMC layer to be a bit more flexible, but
there is one thing that has me baffled; how do you add attributes to an object
in a race free manner when you have a dynamic set of attributes.
I've looked at other parts of the kernel and they all use:
1. Add
20 matches
Mail list logo
