mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Kevin O'Connor" <kevin@koconnor.net>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: Linus Torvalds <torvalds@osdl.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.3-rc1
Date: Sat, 7 Feb 2004 12:21:52 -0500	[thread overview]
Message-ID: <20040207172152.GA6412@arizona.localdomain> (raw)
In-Reply-To: <20040207025638.GW21151@parcelfarce.linux.theplanet.co.uk>

On Sat, Feb 07, 2004 at 02:56:38AM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> One note: please, please, let's put a moratorium on sysfs-related patches
> that didn't go through review.  We are just getting netdev situation in
> the main tree under control.  It took nearly half a year (if not more).
[...]
> If you are doing any sysfs integration - *fix* *lifetime* *rules* *first*.

There appears to be a lot of developer activity concentrated on getting
sysfs support in various parts of the kernel, and this inevitably leads to
a reworking of kernel object lifetime rules.  I have to wonder if making
these lifetime changes is really a good idea.

Sysfs appears to be mainly used for exporting various adhoc pieces of
information and occasionally for getting various tuning input.  This
functionality is generally ancillary to the main purpose of the
subsystems/drivers that use sysfs.  It seems backward to me that the
lifetime rules of an object should be dominated by this ancillary
functionality.

So, my question - is it really a good idea to rework much of the kernel
object lifetime rules just to support sysfs?

And a related question - couldn't sysfs be taught to atomically drop its
references to external kernel objects and thus obviate the need for all
these lifetime rule changes?

-Kevin

-- 
 ---------------------------------------------------------------------
 | Kevin O'Connor                  "BTW, IMHO we need a FAQ for      |
 | kevin@koconnor.net               'IMHO', 'FAQ', 'BTW', etc. !"    |
 ---------------------------------------------------------------------

  reply	other threads:[~2004-02-07 17:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-07  2:28 Linus Torvalds
2004-02-07  2:56 ` viro
2004-02-07 17:21   ` Kevin O'Connor [this message]
2004-02-07 19:20     ` Greg KH
2004-02-07  3:11 ` Måns Rullgård
2004-02-07  5:26   ` Greg KH
2004-02-07 10:24 ` Andre Tomt
2004-02-07 16:22   ` Bartlomiej Zolnierkiewicz
2004-02-08  6:02     ` Andre Tomt
2004-02-08  6:29       ` Andre Tomt
2004-02-08 21:34       ` Bartlomiej Zolnierkiewicz
2004-02-08 21:55         ` Andre Tomt
2004-02-08 22:51           ` Bartlomiej Zolnierkiewicz
2004-02-09  0:08             ` Andre Tomt
2004-02-09  1:34               ` Bartlomiej Zolnierkiewicz
2004-02-09  2:40                 ` Andre Tomt
2004-02-09 12:41                   ` Arkadiusz Miskiewicz
2004-02-09 14:41                     ` Bartlomiej Zolnierkiewicz
2004-02-09 13:01                   ` Bartlomiej Zolnierkiewicz
2004-02-09  1:53           ` Disassembling with gdb (Re: Linux 2.6.3-rc1) Matthew Reppert
2004-02-08 15:18 ` Linux 2.6.3-rc1 Geert Uytterhoeven

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=20040207172152.GA6412@arizona.localdomain \
    --to=kevin@koconnor.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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

all inboxes | Powered by JetHome®