From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: linux-next: Tree for August 14 (sysfs/acpi errors) Date: Sat, 16 Aug 2008 20:40:51 -0700 Message-ID: <20080817034051.GA26849@kroah.com> References: <20080814172945.250a27f2.sfr@canb.auug.org.au> <20080814083828.d10e126d.randy.dunlap@oracle.com> <3ae72650808150427q364842ccicf0a0978b30ca98c@mail.gmail.com> <20080815085836.67e420f1.randy.dunlap@oracle.com> <1218854219.3629.30.camel@lgn.site> <48A64235.2030108@linux.intel.com> <1218856798.3629.45.camel@lgn.site> <48A64E0A.8090408@linux.intel.com> <20080816044714.GA19886@kroah.com> <48A78D4A.70609@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <48A78D4A.70609@linux.intel.com> Sender: linux-acpi-owner@vger.kernel.org To: Andi Kleen Cc: Kay Sievers , Randy Dunlap , Stephen Rothwell , linux-next@vger.kernel.org, LKML , linux-acpi@vger.kernel.org, rusty@rustcorp.com.au List-Id: linux-next.vger.kernel.org On Sun, Aug 17, 2008 at 04:30:34AM +0200, Andi Kleen wrote: > Greg KH wrote: >> On Sat, Aug 16, 2008 at 05:48:26AM +0200, Andi Kleen wrote: >>>> They have been module options, not prefixed kernel parameters so f= ar, >>>> and the prefix was just the module name. >>>> So it just strikes back, that acpi uses generic names for the modu= les, >>>> there would have been no problem if "power" would be called "acpi_= power" >>>> and the options would just be =EF=BB=BF"acpi.acpica_version" and >>>> "acpi_power.nocheck". >>>> But well, there are driver modules just called "option", so acpi i= s not >>>> that bad. :) >>>>> I think the generic params code should be fixed to handle this. >>>> We could try to look up existing directories to use instead of exp= ecting >>>> that we need to create and own them. I guess, >>> sysfs does this anyways, doesn't it. We would just need to teach it >>> to not BUG() in this case, perhaps with a special entry point. >>> Also a BUG() in general seems a little harsh for this, surely a WAR= N_ON >>> should be enough. >> It is a WARN() call, not a BUG(). > > Ok. Can we remove it? Or add a new entry point that allows to disable= it? No! What you are doing here is wrong, trying to create two files with the same name. You just should not be doing that at all, it's that simple. =46ix the broken code/link order, don't paper it over in the sysfs laye= r. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html