All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: "Teras Timo (EXT-YomiGroup/Helsinki)" <Ext-Timo.Teras@nokia.com>
Cc: Robert Love <rml@novell.com>, linux-kernel@vger.kernel.org
Subject: Re: kobject events questions
Date: Fri, 1 Oct 2004 12:22:38 -0700	[thread overview]
Message-ID: <20041001192238.GA24404@kroah.com> (raw)
In-Reply-To: <20041001184714.GA19587@two.research.nokia.com>

On Fri, Oct 01, 2004 at 09:47:14PM +0300, Teras Timo (EXT-YomiGroup/Helsinki) wrote:
> On Fri, Oct 01, 2004 at 09:47:50AM -0700, ext Greg KH wrote:
> > > I'm just a bit dubious about adding new signals since they are hardcoded 
> > > in the kernel. It's a time consuming process to add new signals (either 
> > > for development build or for official kernels). This is one of the 
> > > reasons I liked more about the original kevent patch. Wouldn't simple 
> > > #defines have been enough for signal names?
> > 
> > What's the difference between a #define and a enum?  We want these to be
> > well known, and correct.  A enum gives us that.
> 
> I was a bit ambiguous. I meant #defines with string literals. That would
> have assured correct signal names. I guess to have them all well known
> justifies for enums (even though it makes adding new ones a bit more
> difficult).

That's the point.  It should "be difficult" in that you need to present
a valid reason to the whole kernel community as to why a new event needs
to be added.  But if you make a point that others agree with, then there
should be no problem in adding it.

thanks,

greg k-h

  reply	other threads:[~2004-10-01 19:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-29 13:37 kobject events questions Timo Teräs
2004-09-29 19:39 ` Robert Love
2004-10-01  9:51   ` Timo Teräs
2004-10-01 16:47     ` Greg KH
2004-10-01 18:47       ` Teras Timo (EXT-YomiGroup/Helsinki)
2004-10-01 19:22         ` Greg KH [this message]
2004-10-06 10:39           ` Timo Teräs
2004-09-29 23:35 ` Greg KH

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=20041001192238.GA24404@kroah.com \
    --to=greg@kroah.com \
    --cc=Ext-Timo.Teras@nokia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@novell.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 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.