[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070328012635.GC18799@zenigma>
Date: Wed, 28 Mar 2007 03:26:35 +0200
From: Eric Rannaud <eric.rannaud@...il.com>
To: Cornelia Huck <cornelia.huck@...ibm.com>
Cc: Kay Sievers <kay.sievers@...y.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Larry Finger <larry.finger@...inger.net>,
Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org,
linux-wireless@...r.kernel.org,
Monakhov Dmitriy <dmonakhov@...nvz.org>
Subject: Re: 2.6.21-rc4-mm1
On Tue, Mar 27, 2007 at 07:17:49PM +0200, Cornelia Huck wrote:
> On Tue, 27 Mar 2007 11:25:57 +0200,
> "Kay Sievers" <kay.sievers@...y.org> wrote:
> > Checking the uevent return value, will not prevent any malfunction,
> > usually this kind of "error handling" just prevents bringing up a
> > whole subsystem, or booting-up a box, because the needed device does
> > not exist at all.
>
> OK, if we consider uevents to be non-vital to a functioning device.
The reason for that original patch was that it is actually possible for the
uevent functions to return -ENOMEM, the uevent buffer being statically
allocated to BUFFER_SIZE (2048). It used to be 1024 but that was not
always enough and it was doubled a while ago [1]. Using add_uevent_var()
makes this less of a problem as such an overflow should be catched
cleanly [2].
> OTOH, I think using something like uevent_suppress (maybe via
> dev_uevent_filter?) is a saner way to suppress a uevent than to return
> an error code in the uevent function.
That makes sense, I guess. I will try that.
Thanks.
[1] http://marc.info/?t=113797361200002&r=1&w=2
[2] uevent-use-add_uevent_var-instead-of-open-coding-it.patch in rc4-mm1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists