All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Q: sysfs usage of various devices/subsystems
Date: Sat, 25 Nov 2006 14:41:47 +0300	[thread overview]
Message-ID: <45682BFB.4030202@tls.msk.ru> (raw)

Linux has a variety of different devices and subsystems.
For example, tun/tap devices, bridge devices, ethernet
and ATM devices, routing, serial ports, printer ports,
floppies and so on.

And each such subsystem usually comes with its own control
program.  Like, tunctl, brctl, ethtool, miitool, slattach,
even ifconfig and route (or ip), setserial, tunelp etc.

The question is: can't it all be done from sysfs, so that
there's no need to have millions of tiny control programs
around but only shell will be sufficient?

For example, for tunctl, it's not at all difficult to have
something like this:

 # create new tun
 echo tap12 > /sys/class/misc/tun/new-tap
 # assign owner (uid)
 echo 1234 > /sys/class/net/tap12/owner

This is equivalent to tunctl -u 1234 tap12.  And

  echo y > /sys/class/net/tap12/delete

is equivalent to tunctl -d tap12.

Or, for tunelp:

  tunelp lp0 -i 10	echo 10 > /sys/class/printer/lp0/irq
  tunelp lp0 -t 10	echo 10 > /sys/class/printer/lp0/time
  tunelp lp0 -c 1000	echo 1000 > /sys/class/printer/lp0/chars
  tunelp lp0 -r         echo y > /sys/class/printer/lp0/reset

and so on.

Just to show an "idea".

The same is possible even for routing table manipulation and
as a complete replacement of ifconfig (modulo the name->ip
address resolution which kernel obviously should not do), but
those subsystems are more complex.

And currently, at least some devices/subsystems implements
exactly this way.  For example, SCSI subsystem, which has
  /sys/class/scsi_device/XXX/device/rescan
and
  /sys/block/sdX/device/delete

Also, some drivers uses this sysfs way for configuration and
management, like for QLogic iSCSI controllers.

What's the general consensus about all this?  Is it not being
done because of the lack of common agreement that this way is
THE way to go, or just because of the lack of the time or too
low priority of this task?

Thanks.

/mjt

                 reply	other threads:[~2006-11-25 11:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=45682BFB.4030202@tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.