From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Kay Sievers <kay.sievers@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Paul Mundt <lethal@linux-sh.org>, Greg KH <gregkh@suse.de>,
Linux PM mailing list <linux-pm@lists.linux-foundation.org>,
Russell King <linux@arm.linux.org.uk>,
Magnus Damm <magnus.damm@gmail.com>,
linux-sh@vger.kernel.org
Subject: Re: [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev
Date: Tue, 22 Mar 2011 23:42:20 +0100 [thread overview]
Message-ID: <201103222342.20526.rjw@sisk.pl> (raw)
In-Reply-To: <1300832411.1815.35.camel@zag>
On Tuesday, March 22, 2011, Kay Sievers wrote:
> On Tue, 2011-03-22 at 23:05 +0100, Rafael J. Wysocki wrote:
> > On Tuesday, March 22, 2011, Kay Sievers wrote:
> > > On Tue, 2011-03-22 at 22:00 +0100, Rafael J. Wysocki wrote:
> > > > On Tuesday, March 22, 2011, Kay Sievers wrote:
> > > > > On Tue, 2011-03-22 at 21:30 +0100, Rafael J. Wysocki wrote:
> > > > > >
> > > > > > Perhaps there's a more straightforward way to make some files show up in
> > > > > > sysfs on a specific path than defininig an otherwise useless bus type and
> > > > > > device object?
> > > > >
> > > > > That's absolutely not the point. Please don't get yourself into that
> > > > > thinking. If people want to "export stuff to userspace", they must not
> > > > > invent new things. We need to get rid of the silly special cases.
> > > >
> > > > Why exactly? Do they actually hurt anyone and if so then how?
> > >
> > > Sure, "devices" are devices, and devices have well-defines set of
> > > properties, not some magic directory, people can mess around with the
> > > way they like.
> >
> > So it looks like the the problem is that the exported attributes happen to
> > be under /sys/devices/. Would it still be a problem if they were somewhere
> > else?
>
> We are not going to invent another location for any devices. They need
> to stay in /devices if they are devices. And all devices need to be
> "struct device".
_They_ _are_ _not_ _devices_.
Please take clocksource as an example. It needs to export two attributes,
available_clocksource and current_clocksource, which are _useful_ user space
interfaces. Why the heck are you trying to convince me it's a good idea to
create a special bus type and struct device _specifically_ for exporting them?!
Moreover, is there anything device-alike in those two attributes? I don't
really think so.
So please stop arguing this way, because it simply isn't going to fly and
people will always say a big fat "no" to such ideas, for a good reason.
> > > > > Userspace is not meant to learn subsystem specific rules for every new
> > > > > thing.
> > > >
> > > > That depends a good deal of who's writing the user space in question. If
> > > > that's the same person who's working on the particular part of the kernel,
> > > > I don't see a big problem.
> > >
> > > Not for "devices". There are rules for devices, which are defined by the
> > > driver core, and the sysdev stuff needs to go, because it does not fit
> > > into that model.
> >
> > OK, I understand that.
> >
> > Now, there's stuff that doesn't really match the "device" model. Where is
> > the right place to export that? Perhaps we should add something like
> > /sys/platform/ (in analogy with /sys/firmware/)?
>
> No, add a subsystem (bus_type) for any of them, and register them. There
> is no such thing as "devices which do not fit the device model", they
> are all fine there. Please stop optimizing single bytes and creating a
> mess in /sys. Every device is a "struct device".
Again. Those things are _not_ devices. Am I not clear enough?
> Think of "struct bus_type" as "struct subsystem", we will rename that
> when we are ready. It is just a group of devices which are of the same
> type, it has nothing to do with a bus in the sense of hardware.
>
> We need unified exports of _all devices to userspace, not custom layouts
> in /sys.
>
> There's is a pretty much outdated Documentation/sysfs-rules.txt, wich
> covers part of the history and the plans.
You seem to be thinking that anything exported through sysfs needs to be
device, which I don't think is event approximately correct (what about
/sys/firmware/ or /sys/kernel/ or /sys/fs/ , for a few examples?).
Think this way: it is useful (and IMHO correct) to export some things to
user space that without necessarily regarding them as "devices", physical
or not. Some of them _happen_ to be exported through sysdevs, but that
doesn't really mean the _are_ devices. They are simply _software_ interfaces
to things that have no device representation and don't _need_ one.
> > > > > There is _one_ way to export device attributes, and that is
> > > > > "struct device" today.
> > > > >
> > > > > If that's to expensive for anybody, just don't use sysfs. It's the rule
> > > > > we have today. :)
> > > >
> > > > Oh, good to know. It's changed a bit since I last heard. Never mind.
> > >
> > > Oh, don't get me wrong, this is all is about "devices" not any other
> > > controls.
> > >
> > > > Still, I won't let you change the things in /sys/power to struct devices,
> > > > sorry about that. ;-)
> > >
> > > Fine as long as they are power specific things, and not "devices". You
> > > don't have sysdevs there, right? :)
> >
> > No, I don't.
>
> Then all is fine. All other stuff is more like /proc, and can never be
> really unified.
YES! And _that_'s precisely what I'm (and Paul is) talking about.
> All we care about is devices, which have common methods
> for userspace to trigger and consume, and need to be unified. Power
> specific control files seems all fine in its kobject use.
I understand that, really.
> > > > And I wonder how are you going to deal with clocksource exporting things
> > > > via the sysdev interface right now. I'd simply create two directories and
> > > > put the two files into them and be done with that, but I guess that
> > > > wouldn't fit into the model somehow, right?
> > >
> > > Nope, register a bus_type, and use struct device for all of them, Parent
> > > them to /sys/devices/system/ if they should keep their location and
> > > layout.
> >
> > Well, I'll be watching what happens to the patch trying to do that, but I'm
> > not going to bet anything on its success. ;-)
>
> It should be pretty straight-forward. We will need to do that for CPUs I
> guess, because the interface is kinda commonly used.
No. CPUs are _very_ special.
> > > > > > > That way userspace can properly enumerate them in a flat list
> > > > > > > in /sys/bus/<bus_type name>/devices/*, and gets proper events on module
> > > > > > > load and during system coldplug, and can hook into the usual hotplug
> > > > > > > pathes to set/get these values instead of crawling magicly defined and
> > > > > > > decoupled locations in /sys which can not express proper hierarchy,
> > > > > > > classicication, or anything else that all other devices can just do.
> > > > > >
> > > > > > There's no hotplug involved or anything remotely like that AFAICS.
> > > > > > There are simply static files as I said above, they are created
> > > > > > early during system initialization and simply stay there.
> > > > >
> > > > > That's not the point. It's about a single way to retrieve information
> > > > > about devices, extendability, and coldplug during bootup, where existing
> > > > > devices need to be handled only after userspace is up.
> > > >
> > > > I'd say the case at hand has nothing to do with that.
> > >
> > > It has. As for CPUs. We can not do proper CPU-dependent module
> > > autoloading, because the events happen before userspace runs, and
> > > clodplug can not see the broken sysdevs, because they have no events to
> > > re-trigger, like all others have.
> >
> > Well, as I said, would it be OK if the things in question happened to be
> > located somewhere outside of /sys/devices/ ?
>
> No, no device directory can be outside of /sys/devices.
Sorry, I'm repeating that for the last time. I'm not talking about devices.
I'm talking about _totally_ _random_ _stuff_ which is "like /proc, and can
never be really unified" (your own words) which _happens_ to be exported
through the sysdev interface, because that happend to be _easy_ at one point.
Can we agree on that at least?
Thanks,
Rafael
next prev parent reply other threads:[~2011-03-22 22:42 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 0:31 [RFC][PATCH 0/2] Allow subsystems to avoid using sysdevs for defining "core" PM callbacks Rafael J. Wysocki
2011-03-10 0:33 ` [RFC][PATCH 1/2] Introduce struct syscore_ops and related functionality Rafael J. Wysocki
2011-03-10 3:33 ` [linux-pm] " Alan Stern
2011-03-10 10:42 ` Rafael J. Wysocki
2011-03-10 11:30 ` [RFC][Update][PATCH " Rafael J. Wysocki
2011-03-11 17:11 ` Greg KH
2011-03-11 20:13 ` Rafael J. Wysocki
2011-03-11 20:16 ` Greg KH
2011-03-11 20:33 ` Rafael J. Wysocki
2011-03-10 0:34 ` [RFC][PATCH 2/2] Convert several sysdev users to using struct syscore_ops Rafael J. Wysocki
2011-03-11 17:12 ` Greg KH
2011-03-11 20:29 ` Rafael J. Wysocki
2011-03-11 20:33 ` Greg KH
2011-03-11 20:45 ` Rafael J. Wysocki
2011-03-10 13:05 ` [RFC][PATCH 0/2] Allow subsystems to avoid using sysdevs for defining "core" PM callbacks Kay Sievers
2011-03-10 19:04 ` Rafael J. Wysocki
2011-03-12 21:12 ` [PATCH 0/8] " Rafael J. Wysocki
2011-03-12 21:13 ` [PATCH 1/8] PM / Core: Introcude struct syscore_ops Rafael J. Wysocki
2011-03-12 21:15 ` [PATCH 2/8] x86: Use syscore_ops instead of sysdev classes and sysdevs Rafael J. Wysocki
2011-03-13 14:23 ` Thomas Gleixner
2011-03-13 15:07 ` Rafael J. Wysocki
2011-03-12 21:16 ` [PATCH 3/8] ACPI: Use syscore_ops instead of sysdev class and sysdev Rafael J. Wysocki
2011-03-18 21:38 ` Len Brown
2011-03-12 21:17 ` [PATCH 4/8] timekeeping: " Rafael J. Wysocki
2011-03-13 13:56 ` Thomas Gleixner
2011-03-13 15:08 ` Rafael J. Wysocki
2011-03-12 21:18 ` [PATCH 5/8] PCI / Intel IOMMU: " Rafael J. Wysocki
2011-06-02 17:30 ` Tony Luck
2011-06-06 17:57 ` Rafael J. Wysocki
2011-06-06 17:58 ` Luck, Tony
2011-03-12 21:18 ` [PATCH 6/8] KVM: " Rafael J. Wysocki
2011-03-12 21:20 ` [PATCH 7/8] cpufreq: Use syscore_ops for boot CPU suspend/resume Rafael J. Wysocki
2011-03-15 21:43 ` [Update, v2] " Rafael J. Wysocki
2011-03-12 21:21 ` [PATCH 8/8] Introduce ARCH_NO_SYSDEV_OPS config option Rafael J. Wysocki
2011-03-13 13:55 ` Thomas Gleixner
2011-03-13 15:30 ` [Update] " Rafael J. Wysocki
2011-03-13 13:02 ` [PATCH 9-10/10] Allow subsystems to avoid using sysdevs for defining "core" PM callbacks Rafael J. Wysocki
2011-03-13 13:03 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev R. J. Wysocki
2011-03-17 8:20 ` Paul Mundt
2011-03-19 0:47 ` Rafael J. Wysocki
2011-03-22 14:04 ` Paul Mundt
2011-03-22 14:19 ` Kay Sievers
2011-03-22 20:30 ` Rafael J. Wysocki
2011-03-22 20:39 ` Kay Sievers
2011-03-22 21:00 ` Rafael J. Wysocki
2011-03-22 21:12 ` Kay Sievers
2011-03-22 21:49 ` Paul Mundt
2011-03-22 22:00 ` Kay Sievers
2011-03-22 22:23 ` Rafael J. Wysocki
2011-03-22 22:44 ` Kay Sievers
2011-03-22 23:32 ` Rafael J. Wysocki
2011-03-22 23:46 ` Kay Sievers
2011-03-22 23:50 ` Rafael J. Wysocki
2011-03-23 9:45 ` Russell King - ARM Linux
2011-03-22 22:23 ` Paul Mundt
2011-03-23 11:12 ` Mark Brown
2011-03-23 11:28 ` Paul Mundt
2011-03-22 22:05 ` Rafael J. Wysocki
2011-03-22 22:20 ` Kay Sievers
2011-03-22 22:42 ` Rafael J. Wysocki [this message]
2011-03-22 22:56 ` Kay Sievers
2011-03-22 23:05 ` Kay Sievers
2011-03-22 23:47 ` Rafael J. Wysocki
2011-03-22 20:19 ` Rafael J. Wysocki
2011-03-23 9:59 ` Paul Mundt
2011-03-23 20:39 ` Rafael J. Wysocki
2011-03-13 13:04 ` [PATCH 10/10] ARM: Use struct syscore_ops instead of sysdevs for PM in timer and leds Rafael J. Wysocki
2011-03-14 9:06 ` Stephen Boyd
2011-03-14 19:54 ` [Update] " Rafael J. Wysocki
2011-03-21 23:31 ` [PATCH 0/6] Do not use sysdevs for implementing "core" PM operations on x86 Rafael J. Wysocki
2011-03-21 23:34 ` [PATCH 1/6] x86: Use syscore_ops instead of sysdev classes and sysdevs Rafael J. Wysocki
2011-03-21 23:35 ` [PATCH 2/6] timekeeping: Use syscore_ops instead of sysdev class and sysdev Rafael J. Wysocki
2011-03-21 23:36 ` [PATCH 3/6] PCI / Intel IOMMU: " Rafael J. Wysocki
2011-03-22 10:57 ` Joerg Roedel
2011-03-22 22:07 ` Rafael J. Wysocki
2011-03-23 7:48 ` Roedel, Joerg
2011-03-21 23:37 ` [PATCH 4/6] KVM: " Rafael J. Wysocki
2011-03-22 9:18 ` Avi Kivity
2011-03-21 23:38 ` [PATCH 5/6] cpufreq: Use syscore_ops for boot CPU suspend/resume (v2) Rafael J. Wysocki
2011-03-21 23:38 ` [PATCH 6/6] Introduce ARCH_NO_SYSDEV_OPS config option (v2) Rafael J. Wysocki
2011-03-22 10:32 ` [PATCH 0/6] Do not use sysdevs for implementing "core" PM operations on x86 Ingo Molnar
2011-03-22 20:33 ` Rafael J. Wysocki
2011-03-25 22:51 ` [GIT PULL] More power management updates for 2.6.39 Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201103222342.20526.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=gregkh@suse.de \
--cc=kay.sievers@suse.de \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=magnus.damm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).