| Age | Commit message (Collapse) | Author |
|---|
|
kset_find_obj should increment refcount of the found object so users of
the function can safely use returned object
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
Use NULL, not 0, where appropriate.
|
|
build
Well, one of these (fs/block_dev.c) is little non-trivial, but i felt
throwing that away would be a shame (and I did add comments ;-).
Also almost all of these have been submitted earlier through other
channels, but have not been picked up (the only controversial is again the
fs/block_dev.c patch, where Linus felt a better job would be done with
__ffs(), but I could not convince myself that is does the same thing as
original code).
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
o The following patch cleans up sysfs_rename_dir(). It now checks the
return code of kobject_set_name() and propagates the error code to its
callers. Because of this there are changes in the following two APIs. Both
return int instead of void.
int sysfs_rename_dir(struct kobject * kobj, const char *new_name)
int kobject_rename(struct kobject * kobj, char *new_name)
|
|
|
|
|
|
|
|
|
|
Thanks to Hollis Blanchard <hollisb@us.ibm.com> for pointing this out.
|
|
make kobject hotplug mechanism public so that others may call it.
|
|
|
|
If kobject_set_name() is called when the kobject already has a name that was
dynamically allocated (too long for the static array), then we must free that
memory.
Noticed by Jon Corbet.
|
|
From John Rose <johnrose@austin.ibm.com>
The patch below exposes some kset functions for use by modules. In the
development of a PPC64 pci hotplug drv, we have found it necessary to use ksets
of different types under a single subsystem. After discussing with GregKH,
we agreed that this change makes this possible.
|
|
Bah, stupid mistake. After you call ->release(), you cannot touch the object.
|
|
Add ->k_name pointer which points to the name for a kobject. By default, this
points to ->name (the static name array).
Users of kobjects may use the helper function kobject_set_name() (and are
encouraged to do so in all cases). This function will determined whether or
not the name is short enough to fit in ->name. If so, great.
Otherwise, a dyanamic string is allocated and the name is stored there.
->k_name will point to that, and will be freed when the kobject is released.
kobject_set_name() may take a format string, like:
kobject_set_name(kobj,"%s%d",base_name,id);
and will behave as expected (will put in ->name, unless it's too long, in
which case a new string will be allocated and it will be stored in there).
|
|
Based on a patch written by Dan Aloni <da-x@gmx.net>
|
|
|
|
Previously, we would insert kobjects into their kset's lists at different
locations based on if they had a parent or not - We kept an explicit
depth-first list by placing devices directly before their parents.
However, we don't need strict ordering. Assuming that a subordinate device
is always added after its parent (true), then by adding them to the end of
the list, then subordinate objects will always be farther down the list than
their parent objects. We don't need to do anything special..
|
|
|
|
The only thing preventing this from happening earlier was the circular sysfs
registration dependency - it would need to be initialized before it was
registered, but needed to be registered before it was initialized.
With kobjects gone from struct filesystem_type, the dependency no longer
exists and we don't have to special-case the possibility that a kobject will
be passed to kobject_get with a refcount == 0.
Note that a kobject with a count of 0 in that function is still a bug, but
one in the subsystem making the call. We should add a debugging hook to dump
the stack if it does happen.
|
|
- Make it very explicit that supplying an object desctructor is imperative
if using the interface for object reference counting.
- Add GPL statement to the source files.
- Add GFL (http://www.fsf.org/licenses/fdl.html) statement to documentation.
|
|
into osdl.org:/home/mochel/src/kernel/devel/linux-2.5-core
|
|
This is because some subsystems (cough, usb...) can grab a kobject from irq context.
This lock can be completely removed once the sysfs_init() code is cleaned up.
Patch originally by Andrew Morton.
|
|
From Steve Hemminger (shemminger@osdl.org)
|
|
- allocated storage `envp' was being leaked on an error path
- kmalloc() returns void*, no need to cast it
- don't return 0 from a void-returning function
Greg has acked this patch.
|
|
This only happens if a kobject belongs to a subsystem that has specified
a set of hotplug operations.
Based on work done by Kevin Fleming <kpfleming@cox.net>
|
|
From Louis Zhang.
|
|
Originally from Louis Zhang.
|
|
- From Greg k-h
|
|
The operation is simple:
- Take read lock for kset.
- Iterate over kset->list.
- Compare name to each kobject's name.
- Return kobject if found.
|
|
The kobject core no longer references a subsystem directly through a kobject,
instead using the kobject's dominant kset to reference the subsystem. The
registrants of kobjects have been fixed up.
To aid in this process, a few helpers were introdcuced:
- kobj_set_kset_s(obj,subsys)
- kset_set_kset_s(obj,subsys)
- subsys_set_kset(obj,subsys)
that set the kset ptr of embedded kobjects for objects that have different
embedded types. See include/linux/kobject.h for more description and usage.
struct subsystem::kobj is also removed, relying solely on a subsystem's
embedded kset for hierarchy information. Since this requires modification
of the subsystem declarations, a helper macro has been defined:
decl_subsys(name,type)
which initializes the name and ktype fields of the subsystem's embedded
kset. All the subsystem declarations have been fixed up.
|
|
struct kset is what struct subsystem should have originally been called. It
is a set of kobjects, and nothing more, with a much less confusing name than
'subsystem.'
struct kset contains an embedded kobject, making it possible to represent it
in the object hierarchy, and sysfs. This also provides a means for objects
to easily express a list of subordinate objects.
struct subsystem still exists, and contains an rwsem, which its subordinate
ksets use to protect their lists.
An arbitrary number of ksets may belong to a subsystem. A ksets specifies
the subsystem it belongs to via its ->subsys field.
struct subsystem also contains a default kset, which may be used without
having to define a separate kset.
The objects that defined subordinate subsystems (bus and class drivers) have
been converted to use subordinate ksets instead.
Note that the usage of ksets is flexible.
- ksets may contain a list of objects of any type, not just kobjects.
- The objects registered with a kset do not have to be registered.
- ksets themselves do not have to be registered. One can be used by
simply calling kset_init().
- ksets do not need a name if they are not registered.
- Note however that locking must be done manually in these cases.
|
|
This is the first step in morphing struct subsystem into something meaningful.
A subsystem is defined simply as a list of kobjects of a certain type, which
is far too generic. A subsystem should be representative of a large entity
of code (i.e. a subsystem of the kernel), not just a simple list.
This changeset:
- Creates struct kobj_type, a descriptor of the type a kobject is embedded
in.
- Extracts the fields that are specific to a particular object type from
struct subsystem and puts them in struct kobj_type, which are
- the object's release method.
- the sysfs operations for the object type.
- the default attributes of the object type.
- Adds ptr to struct kobject to point to its type descriptor.
- Converts the existing subsystem definitions to define struct kobj_type.
struct kobj_type's are not registered, as they do not have any explicit
representation in the object hierarchy, nor do they have any fields that
need runtime initialization.
A kobject's ktype should be set when it is registered, like its subsystem.
Note this obviates the need for defining a struct subsystem when an object
type does not need to be kept in a global list.
|
|
- check if subsystem is NULL during subsys_get().
- Don't increment parent's reference count before we check if we have a
valid kobject during kobject_add()
- Do kobject_add() in subsys_register(), instead of kobject_register(),
since we've already done kobject_init().
|
|
kobject_register() has the rude behavior that it will attempt to clean up
the kobject if kobject_add() fails. This replaces that with a WARN_ON() for
the return value, and leaves the cleanup to the caller.
|
|
This is really handy for subsystems that have any attributes they want
to export, esp. if they have just a few, since they don't have to define
all of the infrastructure for creating and tearing down the attributes
for the high level type that they are.
- define struct subsys_attribute for declaring attributes of subsystems
themselves.
- define subsys_create_file() and subsys_remove_file().
- define subsys_sysfs_ops for forwarding sysfs reads and writes to the
subsystem attribute callbacks.
- Set the sysfs_ops to be the subsystem ones if the kobject doesn't belong
to a subsystem itself (meaning that it is a subsystem).
|
|
The interface should now be more sane and protect against races better.
kobject_register() was split into two helpers: kobject_init() and kobject_add().
It calls both consecutively, though both are also exposed for use by users
that want to use the objects w/o adding them to the object hierarchy.
kobject_unregister() was made simply a wrapper for kobject_del() and
kobject_put(), which are both also exposed. The guts of kobject_put() was
moved into kobject_cleanup(), which it calls when the reference count hits
0. (This was done for clarity).
The infrastructure now takes a lot in kobject_get() and kobject_put() when
checking and modifying the objects' reference counts. This was an obvious
one that hsould have been fixed long ago.
kobject_add() increments the refcount of the object, which is decremented
when kobject_del() is called. This guarantees that the object's memory
cannot be freed if it has been added to the hierarchy, and kobject_del()
has not been called on it.
kobject_init() is now the function that increments the refcount on the
object's subsystem, which is decremented only after its release() method
has been called for the object in kobject_cleanup().
The documentation has been updated to reflect these changes.
|
|
...since macro using it was changed from #if to #ifdef..
|
|
This allows subsystems to exist the hierarchy, but not be exported via
the filesystem. This fixes a minor flaw with partitions, as partition
objects are children of block devices, though they register with the
partition subsystem. Really, the partition subsystem shouldn't have
presence in the tree at all, yet still exist.
|
|
|
|
registration.
struct subsystem may now contain a pointer to a NULL-terminated array of
default attributes to be exported when an object is registered with the subsystem.
kobject registration will check the return values of the directory creation and
the creation of each file, and handle it appropriately.
The documentation has also been updated.
|
|
A struct subsystem is basically a collection of objects of a certain type,
and some callbacks to operate on objects of that type.
subsystems contain embedded kobjects themselves, and have a similar set of
library routines that kobjects do, which are mostly just wrappers for the
correlating kobject routines.
kobjects are inserted in depth-first order into their subsystem's list of
objects. Orphan kobjects are also given foster parents that point to their
subsystem. This provides a bit more rigidity in the hierarchy, and disallows
any orphan kobjects.
When an object is unregistered, it is removed from its subsystem's list. When
the objects' refcount hits 0, the subsystem's ->release() callback is called.
Documentation describing the objects and the interfaces has also been added.
|
|
structures.
This is not meant to be fancy; just something simple for which we can
control the refcount and other common functionality using common code.
The basic operations for registration and reference count manipulation are
included.
|
