From: Peter Hurley <peter@hurleysoftware.com>
To: George Spelvin <linux@horizon.com>
Cc: giometti@enneenne.com, gregkh@linuxfoundation.org,
jslaby@suse.cz, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org
Subject: Re: [PATCH 3/4] pps: Use lookup list to reduce ldisc coupling
Date: Wed, 06 Feb 2013 15:09:26 -0500 [thread overview]
Message-ID: <1360181366.5226.19.camel@thor.lan> (raw)
In-Reply-To: <20130206193415.10769.qmail@science.horizon.com>
On Wed, 2013-02-06 at 14:34 -0500, George Spelvin wrote:
> > Now that N_TTY uses tty->disc_data for its private data,
> > 'subclass' ldiscs cannot use ->disc_data for their own private data.
> >
> > Use a lookup list to associate the tty with the pps source.
>
> Thanks for the cleanup. I fully agree my patch was not a good one;
> I just wanted someone more experienced to make the call on rearchitecting.
>
> In particular, I was nervous about getting flamed by Linus for something that
> was too ambitious.
No problem and I completely understand. That's why I jumped in -- it
looked like some help was needed, both now and maybe even in iterations
before this.
> One thing I'd prefer to do would be to change:
>
> +static struct pps_device *lookup_pps_by_tty(struct tty_struct *tty,
> + struct pps_data **p)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&pps_lock, flags);
> + list_for_each_entry((*p), &pps_list, link) {
> + if ((*p)->tty == tty) {
> + spin_unlock_irqrestore(&pps_lock, flags);
> + return (*p)->pps;
> + }
> + }
> + spin_unlock_irqrestore(&pps_lock, flags);
> + return NULL;
> +}
>
> to:
>
> static struct pps_data *lookup_pps_by_tty(struct tty_struct *tty)
> {
> unsigned long flags;
>
> spin_lock_irqsave(&pps_lock, flags);
> list_for_each_entry(p, &pps_list, link) {
> if (p->tty == tty)
> break;
> }
> spin_unlock_irqrestore(&pps_lock, flags);
> return p;
> }
>
> And do the data->pps dereferencing in the caller.
I did this first and it's a mess -- the patch basically ends up looking
like a rewrite. But feel free to use these patches as a base for a
version you do like and submit those instead for review. I just wanted
to show the way.
(Well, actually that was the second version. When I reviewed the
uart_handle_dcd_change() and saw the separate timestamp, I thought that
maybe the latency was going to be a problem. So the first version used
the same approach but with an rcu 'lockless' list instead -- then I went
back and audited the IRQ path and realized there were 5 bus locks and an
i/o port read already. So total overkill.)
Also, I figured maybe it would be best if it was something maintainable
with basic kernel knowledge.
> A more ambitious cleanup would use the existing pps_device list
> (maintained to allocate minor device numbers) and add an "owner" field
> that can be looked up on, without creating a new data structure and
> allocation.
Didn't see where that was (unless you mean the IDR allocation). Probably
best to keep it separate in the event that relative lifetimes change at
some point in the future.
> (It could either be a generic "void *", or a "struct device *" and
> compare it to tty->dev.)
>
> After all, despite the implementation effort to scale, the total number
> of pps devices in a system is usually at most 1 (I have a computer where
> I run 2, and I doubt there are many others on the planet who do that.)
I thought that was probably the case which is why a lookup list is an
acceptable solution.
Please let us know if you plan to respin the patches, so these patches
don't get pushed.
Regards,
Peter Hurley
next prev parent reply other threads:[~2013-02-06 20:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 1:03 3.8-rc regression with pps-ldisc due to 70ece7a731 George Spelvin
2013-02-04 4:18 ` George Spelvin
2013-02-04 7:08 ` George Spelvin
2013-02-06 16:15 ` Peter Hurley
2013-02-06 15:53 ` Peter Hurley
2013-02-06 19:45 ` George Spelvin
2013-02-06 20:31 ` Peter Hurley
2013-02-06 15:55 ` [PATCH 0/4] tty, pps: decouple pps Peter Hurley
2013-02-06 15:55 ` [PATCH 1/4] pps: Decouple N_PPS from N_TTY Peter Hurley
2013-02-06 15:55 ` [PATCH 2/4] pps: Don't crash the machine when exiting will do Peter Hurley
2013-02-06 15:55 ` [PATCH 3/4] pps: Use lookup list to reduce ldisc coupling Peter Hurley
2013-02-06 16:20 ` Jiri Slaby
2013-02-06 16:41 ` Peter Hurley
2013-02-06 19:34 ` George Spelvin
2013-02-06 20:09 ` Peter Hurley [this message]
2013-02-06 22:19 ` George Spelvin
2013-02-06 23:15 ` Peter Hurley
2013-02-06 15:55 ` [PATCH 4/4] tty: Remove ancient hardpps() Peter Hurley
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=1360181366.5226.19.camel@thor.lan \
--to=peter@hurleysoftware.com \
--cc=giometti@enneenne.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@horizon.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 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).