From: ebiederm@xmission.com (Eric W. Biederman)
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Marcin Slusarz <marcin.slusarz@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Frans Pop <elendil@planet.nl>
Subject: Re: [PATCH] parport/ppdev: fix registration of sysctl entries
Date: Sun, 06 Jul 2008 02:25:30 -0700 [thread overview]
Message-ID: <m1tzf3z7n9.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <20080706081126.GA28946@ZenIV.linux.org.uk> (Al Viro's message of "Sun, 6 Jul 2008 09:11:26 +0100")
Al Viro <viro@ZenIV.linux.org.uk> writes:
> On Sat, Jul 05, 2008 at 11:49:26PM -0700, Eric W. Biederman wrote:
>> So our choices appear to be.
>> - Change the name in sysctl so each parport device always has a unique name.
>> - Only allow one opener of ppdev for a given port.
>
> Can't do - it's a legitimate use of ppdev (several userland programs
> multiplexing the sucker).
Yep. And if didn't happen we wouldn't have the bug report.
>
>> - Take the approach of the initial patch and export to sysctl when we claim
>> the port and unexport when we release the port.
>
> You do realize that we need exclusion around that lazy registration in
> any case? sysctl is not the only problem there...
Totally. I was giving credit to the general idea rather then refering
to specific implementation details.
>> - Give up and simply don't register with sysctl for ppdev.
>>
>> I did a quick google search and I could not find any hits (except for
>> this bug report on devices/ppdev) so I am inclined just to special
>> case ppdev and not even bother registering with sysctl. I did not
>> see any other fields that would have problems with a duplicate name.
>>
>> The only other backwards compatible and viable approach appears
>> to be registering ppdev parport devices when they are claimed.
>>
>> The only reason we would be able to change the name without breakage
>> is if no one uses the /proc interface in which case I don't see a
>> point in continuing to provide it for ppdev.
>
> Not quite. /proc/sys/.../timeslice is a generically documented way to
> tune the damn thing when we have several things on the same port. Note
> that while one of those might be in userland, the rest might be in kernel
> and very different. In this case the parameter is both relevant *and*
> currently usable.
Yes. I was only thinking about killing it off for ppdev. You do have a point
something that is tuning this based on all openers could be looking at it
generically.
> Frankly, I'd go for IDR and rename in cases when we have additional openers.
It looks like we can walk port->physport->devices to see if we are the
first ppdev to register. So that should not be too hard.
That will provide maximum compatibility. Right now the first ppdev on
a minor shows up in sysctl and the rest error out sysctl wise. Having
the others show up at a different name is exactly equivalent except
that they show up.
The unfortunate thing is that we won't have a good way to tie those
additional sysctl entries back to whoever opened them. Oh well.
> _And_ add a mutex around delayed allocation - that's a separate problem.
Yes. We need locking so that only one process can set or clear PP_CLAIMED.
Eric
next prev parent reply other threads:[~2008-07-06 9:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-05 13:21 [PATCH] parport/ppdev: fix registration of sysctl entries Marcin Slusarz
2008-07-05 23:51 ` Al Viro
2008-07-06 0:11 ` Al Viro
2008-07-06 4:05 ` Al Viro
2008-07-06 6:49 ` Eric W. Biederman
2008-07-06 8:11 ` Al Viro
2008-07-06 9:25 ` Eric W. Biederman [this message]
2008-07-06 16:22 ` Eduard - Gabriel Munteanu
2008-07-06 16:08 ` Alan Cox
2008-07-06 17:00 ` Eduard - Gabriel Munteanu
2008-07-06 18:09 ` Alan Cox
2008-07-06 15:12 ` Marcin Slusarz
2008-07-06 15:07 ` Marcin Slusarz
2008-07-06 16:01 ` Arjan van de Ven
2008-07-06 20:35 ` Al Viro
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=m1tzf3z7n9.fsf@frodo.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=elendil@planet.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=marcin.slusarz@gmail.com \
--cc=viro@ZenIV.linux.org.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 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.