On Wed, 2011-03-23 at 06:49 +0900, Paul Mundt wrote: > On Tue, Mar 22, 2011 at 10:12:36PM +0100, 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. > > > This is starting to get silly. In the case of interrupt controllers as > with clocksources the bus abstraction is completely meaningless. I could > register a type of "system" bus, but how would that be any different from > what we have from sysdevs already today? All it does is force people to > duplicate crap all over the place instead and pretend like extra busses > exist in order to fit some arbitrary definition of how the driver model > should work. > > You talk about inventing special interfaces to bypass the device model, > but that's not the case here. Rolling my own interface with kobjects and > attribute groups as with /sys/power or making an arbitrary bus type for a > single class of system devices seems infinitely more hackish than the > current sysdev model. > > The comment at the top of sys.c says: > > * sys.c - pseudo-bus for system 'devices' (cpus, PICs, timers, etc) Which is what we need to get rid of. It does not make any sense on the global picture to have anything like that exported to userspace. > Which is precisely where I would expect interrupt controllers and timers > and CPUs to go. I'm not going to make an IRQ bus or a timer bus and > arbitrarily map some things there and some things somewhere else in the > name of some abstraction insanity. These interrupt controllers all have > consistent attributes that make the sysdev class model work well, but > there are also many other types of interrupt controllers on the same CPUs > that use a different abstraction. > > Beyond that, we also have sysdev class utilization for DMA controllers, > per-CPU store queues, etc, etc. all of which would need to be converted > to something else (see for example arch/sh/kernel/cpu/sh4/sq.c -- which > in turn was modelled after the cpufreq code, which also would need to > change to something else). It's not entirely obvious how to convert these > things, or why one should even bother. I can live with the struct device > overhead even if I find it to be a meaningless abstraction in this case, > but what sort of bus/class model to shoe horn these things in to is > rather beyond me. > > Indeed it seems to me that these are precisely the sorts of things that > sysdevs are intended for, which is why I elected to use them from the > onset. Simply saying "don't use sysdevs" and "pretend like you have some > sort of a magical pseudo-bus that's not a system bus" doesn't quite do it > for me. Nope, a device has a "name", a "subsystem" and a "devpath", has well-defined core-maintained properties at the device directory. It is not some random custom directory which people can put where they like it. Userspace has expectations about devices which need to be met, and that can only happen if these devices are "struct device". All real devices sort into a hierarchy, possibly in different parent locations, and have a single point of classification which is the devices/ directory and contains symlinks. Only that way we can cope with it in userspace. People should really stop messing around in /sys for optimization purposes. We have a common device model, and need to use it. Sysdevs do not fit into that model. I can't tell how that fits into your use case, but please use something else than sysfs, if you need device information exported, but you can't use "struct device". Thanks, Kay _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
