Hello, just a note to tell you guys what's going on.
It's taking more time than I expected but it's near completion. I'm
testing things now. After that, they need to be split and documented.
It'll be a BIG change and due to other things including moronic military
reserve training, I'll probably be able to post it after next week.
Sorry about the delay but I think the result will be pretty good in the end.
* Suicidal nodes don't need special treatment. If a file tries to
commit suicide, sysfs will detect the condition and deactivate and drain
the node except for the suiciding reference.
* much more compact and flexible interface based on sysfs_dirent instead
of kobject.
* Backward compatibility is fully maintained. All kobject based
interface is reimplemented in terms of the new interface.
* Plugged creation and batched error handling. Sysfs directories can be
'plugged' on creation such that it can be made visible atomically after
all its subtrees are constructed. Also, the user doesn't have to check
for failure at every step. For example, the user can do the following.
dir = sysfs_add_dir(parent, "my_dir", SYSFS_PLUGGED | 0777);
sysfs_add_file(dir, ...);
...
dir2 = sysfs_add_dir(dir, ...);
sysfs_add_link(dir, "link-to-dir2", dir2);
...
if (sysfs_check_batch_error(dir) == 0)
sysfs_unplug(dir);
else
sysfs_remove(dir);
And all the nodes under and including @dir will show up atomically if
all operations succeeded or removed without ever bothering userland.
* Automatic symlink handling. Symlink names can be formatted with the
name of its target. e.g. if the symlink name is specified as
"link-%1:%0" and points to "devices/mybus0/mydev0", its name becomes
"link-mybus0-mydev0" && the symlink will be automatically renamed when
the target node or one of its ancestor is moved or renamed. The symlink
is also plugged and removed together with its target. So, once created,
the user doesn't have to care about the symlink. sysfs will take care
of it.
* I think most of the changes wouldn't hinder implementation of tagged
nodes. In fact, most of the new rename logic which handles symlink
rename together is taken from tagged node implementation, so with some
luck it should be easier to support tagged nodes.
*** Future plans.
* Move uevent support over to sysfs and bridging the current users.
This makes sense because sysfs hierarchy is all that userland can see
and sysfs users which don't use kobject also needs uevent support.
* Convert device model (drivers/base/*) over to the new sysfs_dirent
based interface and make device/driver <-> sysfs association flexible.
Automatic sysfs association is a good thing. In most cases, it makes
sense and makes drivers simpler but it also needs to be flexible such
that drivers with special needs can override how the device and driver
are represented to userland. I think such flexibility can be achieved
without too much problem now that sysfs and kobject are separated.
Thanks.
--
tejun
Tejun Heo <[email protected]> writes:
> * Automatic symlink handling. Symlink names can be formatted with the
> name of its target. e.g. if the symlink name is specified as
> "link-%1:%0" and points to "devices/mybus0/mydev0", its name becomes
> "link-mybus0-mydev0" && the symlink will be automatically renamed when
> the target node or one of its ancestor is moved or renamed. The symlink
> is also plugged and removed together with its target. So, once created,
> the user doesn't have to care about the symlink. sysfs will take care
> of it.
Sounds nice.
> * I think most of the changes wouldn't hinder implementation of tagged
> nodes. In fact, most of the new rename logic which handles symlink
> rename together is taken from tagged node implementation, so with some
> luck it should be easier to support tagged nodes.
Hopefully.
> *** Future plans.
>
> * Move uevent support over to sysfs and bridging the current users.
> This makes sense because sysfs hierarchy is all that userland can see
> and sysfs users which don't use kobject also needs uevent support.
This could have an interesting interaction with the namespace work.
I think my current implementation only makes these events visible
in the initial network namespace. But that should change.
Eric
On Sun, Sep 02, 2007 at 10:40:58PM +0900, Tejun Heo wrote:
> Hello, just a note to tell you guys what's going on.
>
> It's taking more time than I expected but it's near completion. I'm
> testing things now. After that, they need to be split and documented.
> It'll be a BIG change and due to other things including moronic military
> reserve training, I'll probably be able to post it after next week.
> Sorry about the delay but I think the result will be pretty good in the end.
>
> * Suicidal nodes don't need special treatment. If a file tries to
> commit suicide, sysfs will detect the condition and deactivate and drain
> the node except for the suiciding reference.
>
> * much more compact and flexible interface based on sysfs_dirent instead
> of kobject.
Why? What would use this kind of interface? Why would you want to
create things in sysfs without a kobject?
> * Backward compatibility is fully maintained. All kobject based
> interface is reimplemented in terms of the new interface.
This is a source level for the sysfs functions compatibility, right? Or
is this the userspace view of sysfs? If the later one, why would that
have changed?
> * Plugged creation and batched error handling. Sysfs directories can be
> 'plugged' on creation such that it can be made visible atomically after
> all its subtrees are constructed. Also, the user doesn't have to check
> for failure at every step. For example, the user can do the following.
>
> dir = sysfs_add_dir(parent, "my_dir", SYSFS_PLUGGED | 0777);
> sysfs_add_file(dir, ...);
> ...
> dir2 = sysfs_add_dir(dir, ...);
> sysfs_add_link(dir, "link-to-dir2", dir2);
> ...
> if (sysfs_check_batch_error(dir) == 0)
> sysfs_unplug(dir);
> else
> sysfs_remove(dir);
>
> And all the nodes under and including @dir will show up atomically if
> all operations succeeded or removed without ever bothering userland.
Is this really needed? We work on kobjects and attributes today, and we
can easily add and remove groups of attributes just fine.
> * Automatic symlink handling. Symlink names can be formatted with the
> name of its target. e.g. if the symlink name is specified as
> "link-%1:%0" and points to "devices/mybus0/mydev0", its name becomes
> "link-mybus0-mydev0" && the symlink will be automatically renamed when
> the target node or one of its ancestor is moved or renamed. The symlink
> is also plugged and removed together with its target. So, once created,
> the user doesn't have to care about the symlink. sysfs will take care
> of it.
This might be nice, it would take code out of kobject_move(), right?
> * I think most of the changes wouldn't hinder implementation of tagged
> nodes. In fact, most of the new rename logic which handles symlink
> rename together is taken from tagged node implementation, so with some
> luck it should be easier to support tagged nodes.
>
> *** Future plans.
>
> * Move uevent support over to sysfs and bridging the current users.
> This makes sense because sysfs hierarchy is all that userland can see
> and sysfs users which don't use kobject also needs uevent support.
What sysfs users without kobjects? Why?
> * Convert device model (drivers/base/*) over to the new sysfs_dirent
> based interface and make device/driver <-> sysfs association flexible.
> Automatic sysfs association is a good thing. In most cases, it makes
> sense and makes drivers simpler but it also needs to be flexible such
> that drivers with special needs can override how the device and driver
> are represented to userland. I think such flexibility can be achieved
> without too much problem now that sysfs and kobject are separated.
Hm, I'll have to wait to see the code to understand what you mean by
this one :)
thanks for all your work on sysfs so far, it is much nicer than it used
to be.
greg k-h
Greg KH wrote:
>> * much more compact and flexible interface based on sysfs_dirent instead
>> of kobject.
>
> Why? What would use this kind of interface? Why would you want to
> create things in sysfs without a kobject?
Compulsory 1:1 mapping between kobject (thus driver model) and sysfs has
been a constant headache for more complex subsystems (e.g. SAS). The
organization of internal implementation is directly visible to userland
making it part of API which shouldn't change. For simpler drivers, this
is fine but for others it's too strict a restriction - internal
representation may have to change as implementation matures and the
desired userland view might differ from internal representation for
multiple reasons.
I'm not saying automatic representation is bad. It's good enough for
90+% of cases and I'm not intending to change that but we still need
flexibility.
Another example would be libata. libata currently is a SCSI driver and
as such its sysfs representation is tied to SCSI. However, it's planned
to become an independent block driver and will thus have a separate
sysfs bus and device representation. The problem is that such
fundamental structure change takes time but libata still needs sysfs
interface now. Features which require sysfs interface are currently
being delayed or stuffed into SCSI sysfs interface, both of which are
far from the optimal situation.
Breaking the tight coupling between the driver model and sysfs
representation is a way to achieve that. sysfs becomes an independent
facility which the driver model uses and, where needed, drivers can
override how it's used. Breaking the tight coupling also makes the
design and implementation of driver model and sysfs more modular and
simpler.
Less pressing but still important is that the current interface is
needlessly cumbersome. IMHO, it can be made much more intuitive for
driver writers. More on this later.
>> * Backward compatibility is fully maintained. All kobject based
>> interface is reimplemented in terms of the new interface.
>
> This is a source level for the sysfs functions compatibility, right? Or
> is this the userspace view of sysfs? If the later one, why would that
> have changed?
Yeap, it's compatible both ways. Keeping those intact has been of
course the top priority. :-)
>> * Plugged creation and batched error handling. Sysfs directories can be
>> 'plugged' on creation such that it can be made visible atomically after
>> all its subtrees are constructed. Also, the user doesn't have to check
>> for failure at every step. For example, the user can do the following.
>>
>> dir = sysfs_add_dir(parent, "my_dir", SYSFS_PLUGGED | 0777);
>> sysfs_add_file(dir, ...);
>> ...
>> dir2 = sysfs_add_dir(dir, ...);
>> sysfs_add_link(dir, "link-to-dir2", dir2);
>> ...
>> if (sysfs_check_batch_error(dir) == 0)
>> sysfs_unplug(dir);
>> else
>> sysfs_remove(dir);
>>
>> And all the nodes under and including @dir will show up atomically if
>> all operations succeeded or removed without ever bothering userland.
>
> Is this really needed? We work on kobjects and attributes today, and we
> can easily add and remove groups of attributes just fine.
>
>> * Automatic symlink handling. Symlink names can be formatted with the
>> name of its target. e.g. if the symlink name is specified as
>> "link-%1:%0" and points to "devices/mybus0/mydev0", its name becomes
>> "link-mybus0-mydev0" && the symlink will be automatically renamed when
>> the target node or one of its ancestor is moved or renamed. The symlink
>> is also plugged and removed together with its target. So, once created,
>> the user doesn't have to care about the symlink. sysfs will take care
>> of it.
>
> This might be nice, it would take code out of kobject_move(), right?
And the above two are efforts to make life easier for driver writers so
that the overhead of using sysfs is minimal. Both features don't
interfere with simple usages and when a driver writer wants to use them,
they don't have to do anything special. They're just there.
>> * Move uevent support over to sysfs and bridging the current users.
>> This makes sense because sysfs hierarchy is all that userland can see
>> and sysfs users which don't use kobject also needs uevent support.
>
> What sysfs users without kobjects? Why?
Hopefully, it's explained now. It's part of breaking the tight coupling
between internal driver implementation and userland representation.
>> * Convert device model (drivers/base/*) over to the new sysfs_dirent
>> based interface and make device/driver <-> sysfs association flexible.
>> Automatic sysfs association is a good thing. In most cases, it makes
>> sense and makes drivers simpler but it also needs to be flexible such
>> that drivers with special needs can override how the device and driver
>> are represented to userland. I think such flexibility can be achieved
>> without too much problem now that sysfs and kobject are separated.
>
> Hm, I'll have to wait to see the code to understand what you mean by
> this one :)
The new interface is simpler, more orthogonal and flexible. The whole
interface is consisted of 11 functions and of the 11 only 9 are needed
to achieve the same functionality the original 16 have. The left two
are for plugged creation support.
Thanks.
--
tejun
On Sun, 02 Sep 2007 22:40:58 +0900,
Tejun Heo <[email protected]> wrote:
> * Suicidal nodes don't need special treatment. If a file tries to
> commit suicide, sysfs will detect the condition and deactivate and drain
> the node except for the suiciding reference.
Excellent. This is so easy to overlook.
> * Plugged creation and batched error handling. Sysfs directories can be
> 'plugged' on creation such that it can be made visible atomically after
> all its subtrees are constructed. Also, the user doesn't have to check
> for failure at every step. For example, the user can do the following.
>
> dir = sysfs_add_dir(parent, "my_dir", SYSFS_PLUGGED | 0777);
> sysfs_add_file(dir, ...);
> ...
> dir2 = sysfs_add_dir(dir, ...);
> sysfs_add_link(dir, "link-to-dir2", dir2);
> ...
> if (sysfs_check_batch_error(dir) == 0)
> sysfs_unplug(dir);
> else
> sysfs_remove(dir);
>
> And all the nodes under and including @dir will show up atomically if
> all operations succeeded or removed without ever bothering userland.
Hm. This sounds like two different things:
- Eliminate the need to check after each operation. Might be a matter
of taste; personally, I prefer checking and unwinding on error.
- Atomic creation/deletion of a bunch of sysfs nodes. This sounds
like something really worthwile to have.
>
> * Automatic symlink handling. Symlink names can be formatted with the
> name of its target. e.g. if the symlink name is specified as
> "link-%1:%0" and points to "devices/mybus0/mydev0", its name becomes
> "link-mybus0-mydev0" && the symlink will be automatically renamed when
> the target node or one of its ancestor is moved or renamed. The symlink
> is also plugged and removed together with its target. So, once created,
> the user doesn't have to care about the symlink. sysfs will take care
> of it.
Really nice. The need to delete/create symlinks on moving/renaming is
currently a headache inducer.
> * Move uevent support over to sysfs and bridging the current users.
> This makes sense because sysfs hierarchy is all that userland can see
> and sysfs users which don't use kobject also needs uevent support.
Makes sense.
>
> * Convert device model (drivers/base/*) over to the new sysfs_dirent
> based interface and make device/driver <-> sysfs association flexible.
> Automatic sysfs association is a good thing. In most cases, it makes
> sense and makes drivers simpler but it also needs to be flexible such
> that drivers with special needs can override how the device and driver
> are represented to userland. I think such flexibility can be achieved
> without too much problem now that sysfs and kobject are separated.
Yes, if we can change internal implementation details without upsetting
userspace a lot is gained. As long as the default behaviour remains
easy to implement.