linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Fox <pgf@laptop.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: can't seem to ignore a battery
Date: Fri, 13 Nov 2009 14:33:06 +0000	[thread overview]
Message-ID: <6184.1258122786@foxharp.boston.ma.us> (raw)
In-Reply-To: <29507.1258042014@foxharp.boston.ma.us>

kay wrote:
 > On Fri, Nov 13, 2009 at 05:54, Greg KH <greg@kroah.com> wrote:
 > > On Thu, Nov 12, 2009 at 09:44:34PM -0500, Paul Fox wrote:
 > >> kay wrote:
 > >>  > On Thu, Nov 12, 2009 at 17:50, David Zeuthen <david@fubar.dk> wrote:
 > >>  > > On Thu, 2009-11-12 at 11:06 -0500, Paul Fox wrote:
 > >>  > >> i'm hoping someone can explain why my rule containing an
 > >>  > >> "ignore_device" option for a power_supply device seems to be
 > >>  > >> ignored. ??some sample output from udevadm test, and udevadm are
 > >>  > >> available here: ??http://pastie.org/695548
 > >>  > >
 > >>  > > Like last_rule (which we covered a few weeks ago), things like
 > >>  > > ignore_device probably needs to go (although I haven't thought much
 > >>  > > about it and I don't know why it was added - probably a broken driver I
 > >>  > > guess). Trying to hide or ignore events at the udev level is just wrong
 > >>  > > on a number of levels.
 > >>  >
 > >>  > Yeah, that's the same issue as last_rule. It's really wrong to show
 > >>  > stuff in sysfs which gets enumerated, but to try to suppress such
 > >>  > events at device creation time.
 > >>
 > >> can someone point me at a thread that explains why being able to
 > >> configure one's system to ignore a device is so plainly wrong?
 > >> i'm clearly missing something.
 > >
 > > Why is your kernel exporting something that you are trying to ignore?
 > > Just fix your kernel driver and it should be no problem, right?
 > 
 > Exactly, we decided not to do this "abstraction game" anymore, and
 > force to fix the kernel where needed, or fix users to cope with such
 > things. As sysfs is the primary interface for many device-related
 > things, including many libudev users, sysfs enumeration will return
 > all devices in all cases, therefore there is not much point in
 > suppressing RUN instructions and hoping that this will hide stuff from
 > users.
 > 
 > "ignore_device" did only suppress the device node creation and RUN
 > instructions, libudev-events are always sent out unconditionally,
 > regardless of any rules. It's all from a time as udev was only

thank you.  i guess this explains the behavior i'm seeing.  i assumed
that ignore_device would cause it to be truly ignored.

clearly we don't _want_ to have two battery drivers for the same
battery.  but neither driver by itself currently fills all of our
current needs, and, given our development schedule, building both
and having the UI layers ignore one of them seemed like the most
expedient, temporary, solution.  we'll have to look at this a
different way.

thanks,
paul

 > managing /dev files, and not all sorts of hotplug setups, today
 > "ignore_device" is just inconsistent, should not be used, and should
 > just be removed.
 > 
 > Thanks,
 > Kay

=---------------------
 paul fox, pgf@laptop.org

  parent reply	other threads:[~2009-11-13 14:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-12 16:06 can't seem to ignore a battery Paul Fox
2009-11-12 16:50 ` David Zeuthen
2009-11-12 17:33 ` Richard Hughes
2009-11-12 17:40 ` Paul Fox
2009-11-12 17:43 ` David Zeuthen
2009-11-13  2:01 ` Kay Sievers
2009-11-13  2:44 ` Paul Fox
2009-11-13  4:54 ` Greg KH
2009-11-13 14:13 ` Kay Sievers
2009-11-13 14:33 ` Paul Fox [this message]
2009-11-13 14:43 ` Justin Schoeman
2009-11-13 16:48 ` Greg KH
2009-11-13 16:49 ` Greg KH
2009-11-13 17:29 ` Justin Schoeman
2009-11-13 17:38 ` Greg KH
2009-11-13 18:22 ` Justin Schoeman
2009-11-13 18:43 ` Paul Fox
2009-11-13 20:33 ` 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=6184.1258122786@foxharp.boston.ma.us \
    --to=pgf@laptop.org \
    --cc=linux-hotplug@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).