[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131105125045.GA18093@kroah.com>
Date: Tue, 5 Nov 2013 04:50:45 -0800
From: Greg KH <gregkh@...uxfoundation.org>
To: Frank Haverkamp <haver@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, arnd@...db.de,
cody@...ux.vnet.ibm.com, schwidefsky@...ibm.com,
utz.bacher@...ibm.com, mmarek@...e.cz, rmallon@...il.com,
jsvogt@...ibm.com, MIJUNG@...ibm.com, cascardo@...ux.vnet.ibm.com,
michael@...ra.de, Frank Haverkamp <haver@...t.ibm.com>
Subject: Re: [PATCH] Generic WorkQueue Engine (GenWQE) device driver (v4)
On Tue, Nov 05, 2013 at 08:16:24AM +0100, Frank Haverkamp wrote:
> Hi Greg,
>
> Am Montag, den 04.11.2013, 14:15 -0800 schrieb Greg KH:
> > > I am using sysfs_create_group() now, but do I understand you
> > correctly
> > > that setting the const struct attribute_group **groups; in my device
> > > (where in my struct pci_device.dev?) is an even better way to
> > establish
> > > my sysfs attributes? Is there a function which I could call rather
> > than
> > > trying to find the right pointer?
> >
> > Ugh, this is still a problem, I'm trying to work through how to have
> > individual drivers implement groups and sysfs files in a non-racy way.
> > The issue is your device was announced to userspace _before_ it was
> > bound to the driver, so there's no way to get the sysfs files to apply
> > before then.
> >
> > You should just have the attributes on the sysfs device you create
> > yourself, not your pci device, as that's where they make more sense,
> > and
> > there you should be able to use the attribute group easily, right?
> >
>
> The current version works well for me and I did not get any complaints
> about the possible race-condition you mentioned so far. So I am happy.
Just because you can't see the race happening, doesn't mean it isn't
there and will not show up for someone else.
A trivial way to see this is write a program that uses libudev that gets
notified when your device shows up and then read the attribute files.
Those files will not be present when your program is notified so the
read will usually fail.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists