From: Aritz Bastida <aritzbastida@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>,
Antonio Vargas <windenntw@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: Right way to configure a driver? (sysfs, ioctl, proc, configfs,....)
Date: Wed, 1 Feb 2006 16:44:44 +0100 [thread overview]
Message-ID: <7d40d7190602010744vc2eaf3fm@mail.gmail.com> (raw)
In-Reply-To: <20060201151145.GA3744@kroah.com>
> > Can't we just somewhat merge all the duplicated functionality between procfs,
> > sysfs and configfs...
>
> What "duplicated functionality"? They all do different, unique things.
>
> Patches are always welcome...
>
> thanks,
>
> greg k-h
>
May be not "duplicated functionality", but _yes_ lots of ways to do
the same thing. I know, that's the magic with Linux, that there are
different ways to achieve the same goal, but in an effort to write
standard, generic, readable code, some ways should be preferred over
others.
As I said in previous messages, my driver is a kind of virtual network
device (imagine something like "snull" in LDD3) and my question was:
what would be the right way to configure it? I know, i know, there is
not a unique question for that, but I'm sure at least there are
suggestions. Some years ago, maybe there was no alternative other than
using system calls or ioctls, but the spectrum is a lot wider now.
I try to resume here the different ways that could be used, and their
original purpose:
* IOCTLS: as far as I know, this is deprecated for new drivers,
although it will still be there for a long time because of backward
compatibility.
* PROCFS: it has been used a lot apart from export process
information, but it seems that finally this is moving toward some new
filesystems (sysfs,configfs).
* SYSFS: this is to export system information
* CONFIGFS: this is to configure kernel modules/subsystems. This is
new to me, and don't have it (at least by default) in my Linux 2.6.15
box (guess it will be in the menuconfig somewhere :P).
* NETLINK: As far as I know this is used for configuring network
devices, routers, firewalls, ...
I guess that, with what I know now (sure more than when I started this
thread), the right ways could be either configfs or netlink. For my
purposes netlink would be more convenient (since the communication
link is bidirectional), but I still don't know if you guys think that
this method is all right.
Bye
Aritz
next prev parent reply other threads:[~2006-02-01 15:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-26 20:06 Right way to configure a driver? (sysfs, ioctl, proc, configfs,....) 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 [this message]
2006-02-01 16:17 ` Jan Engelhardt
2006-02-02 6:31 ` Neil Brown
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=7d40d7190602010744vc2eaf3fm@mail.gmail.com \
--to=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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox