public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Rusty Lynch <rusty@linux.co.intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, Pavel Machek <pavel@ucw.cz>,
	lkml <linux-kernel@vger.kernel.org>,
	Patrick Mochel <mochel@osdl.org>,
	Dave Jones <davej@codemonkey.org.uk>,
	Daniel Pittman <daniel@rimspace.net>
Subject: Re: [PATCH][RFC] Proposal for a new watchdog interface using sysfs
Date: Thu, 20 Feb 2003 22:19:42 +0100	[thread overview]
Message-ID: <20030220211941.GD13216@unthought.net> (raw)
In-Reply-To: <1045632256.2974.76.camel@vmhack>

On Tue, Feb 18, 2003 at 09:24:15PM -0800, Rusty Lynch wrote:
> My original proposal raised a couple of issues with sysfs that make it
> difficult to move completely from the current watchdog model documented in 
> watchdog-api to a completely sysfs based implementation.
> 
> Specifically, sysfs needs:
> * persistent file permissions
> * a way to forward ioctl's or in some way represent a device node in sysfs

Something as simple as a watchdog should not need ioctls, IMO.  (Nothing
should need them, but let's take one battle at a time...)

How about using sysfs and specifically - now that we have a collection
of drivers which are simple enough to not need the mistake that ioctls
are - making sure that they work as before, using only device files and
no magic ioctls ?

I shall happily volunteer to delete the 10 lines of code from
sbc60xxwdt.c to make it compliant to the "no ioctls - equivalent
functionality" idea  ;)

I know that there is ioctl support in the existing drivers - but I have
not yet seen a driver which needed it.   "needed" in the sense that
equivalent functionality could not have been created using dev files
alone.

Also, the amount of userspace which will break because of missing ioctl
functionality will be absolutely *minimal*.  There's not a lot of
watchdog software out there, and porting whatever software uses ioctls
to use sane interfaces instead, should be doable.  I don't think anyone
would get terribly upset if this change was made as a 2.4->2.6
transition thing.

If ioctls are kept in watchdog drivers for 2.6, they can't go away until
2.8/3.0/whatever.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

  reply	other threads:[~2003-02-20 21:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-13  3:16 [PATCH][RFC] Proposal for a new watchdog interface using sysfs Rusty Lynch
2003-02-13  4:27 ` Daniel Pittman
2003-02-13  7:32   ` Rusty Lynch
2003-02-13 11:55 ` Dave Jones
2003-02-13 15:34   ` Rusty Lynch
2003-02-13 16:04     ` Patrick Mochel
2003-02-13 15:51       ` Rusty Lynch
2003-02-13 19:07         ` Dave Jones
2003-02-13 18:31           ` Rusty Lynch
2003-02-13 19:19             ` Patrick Mochel
2003-02-13 21:12               ` Scott Murray
2003-02-13 22:58                 ` Matt Porter
2003-02-13 22:05                   ` Rusty Lynch
2003-02-14  0:47                     ` Rusty Lynch
2003-02-14 14:48                       ` Alan Cox
2003-02-14 15:32                         ` Rusty Lynch
2003-02-14 17:55                           ` Alan Cox
2003-02-14 19:02                             ` Rusty Lynch
2003-02-14 20:43                               ` Alan Cox
2003-02-14 21:12                             ` Joel Becker
2003-02-14 13:48                   ` Valdis.Kletnieks
2003-02-14 14:57                     ` Alan Cox
2003-02-13 16:04     ` Dave Jones
2003-02-13 18:20 ` Rusty Lynch
2003-02-13 18:21 ` Rusty Lynch
2003-02-13 23:04   ` Pavel Machek
2003-02-14 22:12     ` Alan Cox
2003-02-14 21:35       ` Pavel Machek
2003-02-14 23:17         ` Rusty Lynch
2003-02-15  1:54           ` Alan Cox
2003-02-15  8:27             ` Cort Dougan
2003-02-15  9:13               ` John Bradford
2003-02-15 21:03                 ` Alan Cox
2003-02-15 20:37                   ` John Bradford
2003-02-15 12:42               ` Ingo Oeser
2003-02-15 17:26               ` Pavel Machek
2003-02-19  5:24             ` Rusty Lynch
2003-02-20 21:19               ` Jakob Oestergaard [this message]
2003-02-20 22:36                 ` Alan Cox

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=20030220211941.GD13216@unthought.net \
    --to=jakob@unthought.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=daniel@rimspace.net \
    --cc=davej@codemonkey.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=pavel@ucw.cz \
    --cc=rusty@linux.co.intel.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