LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Neil Brown <neilb@suse.de>
To: Greg KH <greg@kroah.com>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Aritz Bastida <aritzbastida@gmail.com>,
	Antonio Vargas <windenntw@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Right way to configure a driver? (sysfs, ioctl, proc, configfs,....)
Date: Thu, 2 Feb 2006 17:31:25 +1100
Message-ID: <17377.42813.479466.690408@cse.unsw.edu.au> (raw)
In-Reply-To: message from Greg KH on Wednesday February 1

On Wednesday February 1, greg@kroah.com wrote:
> On Wed, Feb 01, 2006 at 03:54:22PM +0100, Jan Engelhardt wrote:
> > >> 
> > >> I guess I could pass three values on the same file, like this:
> > >> $ echo "5  1000  500" > meminfo
> > >> 
> > >> I know that breaks the sysfs golden-rule, but how can I pass those
> > >> values _atomically_ then? Having three different files wouldn't be
> > >> atomic...
> > >
> > >That's what configfs was created for.  I suggest using that for things
> > >like this, as sysfs is not intended for it.
> > >
> > Can't we just somewhat merge all the duplicated functionality between procfs,
> > sysfs and configfs...
> 
> What "duplicated functionality"?  They all do different, unique
> things.

So why do you recommend configfs for something that is *almost* what
sysfs does well.

sysfs both exports information, and allows changes to some (not all)
of that information.
But as soon as someone wants an atomic change, which is conceptually a
very small difference, you say "use configfs" which is conceptually a
very big difference in interface.

Configfs - as I read the doco - is not really about providing generic
atomic configuration changes.

Configfs is for *Creating* kernel objects.
The basic sequence is:
  mkdir /config/subsystem/objectname
     # where you choose 'objectname' to be whatever you want.
  echo value > /config/subsystem/objectname/param1
  echo value > /config/subsystem/objectname/param2
  echo value > /config/subsystem/objectname/param3
  echo value > /config/subsystem/objectname/param4

and then the object is ready to go.
Notice that there is *NO* 'commit' step.  There is nothing here that
makes anything atomic.

So saying 'use configfs for atomic updates' doesn't seem rational...

To be fair, configfs is meant to have 'committable items', but they are
'currently unimplemented'.
If you have a 'committable' item, then the sequence instead would go
something like:

   mkdir /config/subsystem/pending/objectname
   echo value > /config/subsystem/pending/objectname/param1
   ...
   mv /config/subsystem/pending/objectname /config/subsystem/live

This does provide atomic updates but, apart from not being
implemented, it only allows atomic updates at object creation time.

If I have a live object, and I want to change some attributes
atomically, configfs DOES NOT LET ME DO THAT.

Conversely, it is quite easy to do this with sysfs.
As you have control over the 'read' and 'write' routines for each
attribute, you simply:
  - in your object, store the real attribute and a 'pending' copy.
  - define a special attribute, maybe called 'commit' such that:
     writing 'clear'  copies the real attributes in to the pending
        copy as well
     writing 'commit' copies the 'pending' copies into the real
        attributes atomically
  - when you write to an attribute, it updates the 'pending' copy.

So to do a atomic update, you:

 1/ get a flock lock on the directory (do sysfs directories support
    flock?)
 2/ write 'clear' to 'commit
 3/ make your changes
 4/ write 'commit' to 'commit
 5/ unflock.

Obvious the 'flock' could be replaced by lockfiles in /tmp or whatever
you want.

This doesn't mean that we don't need configfs (though I'm not yet
convinced).  The point of configfs seems to be *Creating* objects.
Maybe it is a good thing to use for this purpose (though if those
objects end up appearing in sysfs, it would seem like unnecessary
duplication). 
 
> 
> Patches are always welcome...
> 

True, patches are good.
But they don't stop people from recommending the wrong tool for the
job :-)
And they aren't needed to support atomic updates in sysfs.

Maybe what would be good is support for 'mkdir' in sysfs.
I would really like to be able to use 'mkdir' to create md devices,
but '/sys/block' is too flat.  If it had
  /sys/block/sd/scsi-block-devices
  /sys/block/hd/ide-block-devices
  /sys/block/loop/loop-block-devices
it would also have
  /sys/block/md/md-block-devices
and it would make sense to do a 
  mkdir /sys/block/md/0
or whatever to create a new md device.  But I don't think it makes
sense to 
  mkdir /sys/block/md0
because someone would have to parse the device name ('md0') to decide
which module to hand it off to.... oh well :-(

NeilBrown


  parent reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-26 20:06 Aritz Bastida
2006-01-27  5:01 ` Greg KH
2006-01-27 10:30   ` Aritz Bastida
     [not found]     ` <69304d110601270834q5fa8a078m63a7168aa7e288d1@mail.gmail.com>
2006-01-30 11:23       ` Aritz Bastida
2006-01-30 21:39         ` Greg KH
2006-02-01 14:54           ` Jan Engelhardt
2006-02-01 15:11             ` Greg KH
2006-02-01 15:44               ` Aritz Bastida
2006-02-01 16:17                 ` Jan Engelhardt
2006-02-02  6:31               ` Neil Brown [this message]
2006-01-30 21:41     ` Greg KH
2006-02-01 13:37       ` Aritz Bastida
2006-02-01 13:53         ` linux-os (Dick Johnson)
2006-02-01 14:19           ` Aritz Bastida
2006-02-01 15:11             ` linux-os (Dick Johnson)

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=17377.42813.479466.690408@cse.unsw.edu.au \
    --to=neilb@suse.de \
    --cc=aritzbastida@gmail.com \
    --cc=greg@kroah.com \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=windenntw@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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git