From: Ed Vance <EdV@macrolink.com>
To: "'Adam J. Richter'" <adam@yggdrasil.com>
Cc: rmk@arm.linux.org.uk, driver@jpl.nasa.gov, dwmw2@infradead.org,
linux-kernel@vger.kernel.org
Subject: RE: devfs + PCI serial card = no extra serial ports
Date: Fri, 14 Mar 2003 16:54:32 -0800 [thread overview]
Message-ID: <11E89240C407D311958800A0C9ACF7D1A33DE4@EXCHANGE> (raw)
On Fri, Mar 14, 2003 at 4:03 PM, Adam J. Richter wrote:
> On Fri, 14 Mar 2003, Russell King wrote:
> >On Fri, Mar 14, 2003 at 12:28:47PM -0800, Adam J. Richter wrote:
> >> There was tangential mention in that thread
> >> of a "/proc/serialdev" interface, but nobody really identified any
> >> real benefit to it over the existing "uart: unknown" system.
>
> >There is one benefit, which would be to get rid of some of the yucky
> >mess we currently have surrounding the implementation of stuff which
> >changes the port base address/irq.
>
> >Currently, we have to check that we're the only user, shutdown, tweak
> >stuff, hope it all goes to plan, and start stuff back up again. If
> >something fails, we have to pray we can go back to the original setup
> >without stuff breaking. If that fails, we mark the port "unknown".
>
> >All of this would be a lot simpler if we didn't have the
> port actually
> >open at the time we change these parameters. We could just lock the
> >port against opens, check no one was using it, tweak the settings,
> >and release the port. If the changes fail, just report the failure.
>
> When I filter out prejudicial terminology like "yucky mess",
> "pray", "just", etc., I don't see a convincing explanation of how one
> approach is going to result in a lower line count, fewer branches,
> smaller kernel footprint, faster execution, new capabilities or any
> other relevant measure that I can think of in comparison to the
> existing approach.
>
> [ snip ]
Hi Adam,
Oh, but he _did_ give you information about such things. You filtered out
the real message. Allow me to expand the macros ...
yucky mess = referenced area has an unnecessarily complex control
structure. (more branches & code, slower ...)
just = fundamental simplification of the algorithm. (less code and
branching needed because less to do, smaller, faster ...)
hope, pray = referenced area can generate complex errors that cannot
be handled efficiently due to architectural limitations.
(more local error handling code and branching, bigger, slower ...)
expert opinion != prejudicial speech.
Read it again. You'll get the hang of it :-)
Cheers,
Ed
next reply other threads:[~2003-03-15 0:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-15 0:54 Ed Vance [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-03-15 0:02 devfs + PCI serial card = no extra serial ports Adam J. Richter
2003-03-14 20:28 Adam J. Richter
2003-03-14 20:43 ` Russell King
2003-03-14 19:49 Ed Vance
2003-03-14 20:07 ` Russell King
2003-03-14 19:06 Adam J. Richter
2003-03-10 18:37 Adam J. Richter
2003-03-10 17:12 Ed Vance
2003-03-08 19:48 Adam J. Richter
2003-03-10 18:25 ` Bryan Whitehead
2003-03-14 15:23 ` David Woodhouse
2003-03-08 1:30 Ed Vance
2003-03-07 23:57 Ed Vance
2003-03-08 0:59 ` Bryan Whitehead
2003-03-11 9:07 ` Theodore Ts'o
2003-03-07 23:40 Ed Vance
2003-03-08 0:15 ` Marek Michalkiewicz
2003-03-07 23:04 Ed Vance
2003-03-07 23:17 ` Bryan Whitehead
2003-03-07 22:51 Bryan Whitehead
2003-03-07 22:55 ` Bryan Whitehead
2003-03-07 23:28 ` Bryan Whitehead
2003-03-08 0:10 ` Marek Michalkiewicz
2003-03-07 23:38 ` Theodore Ts'o
2003-03-11 23:12 ` whitnl73
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=11E89240C407D311958800A0C9ACF7D1A33DE4@EXCHANGE \
--to=edv@macrolink.com \
--cc=adam@yggdrasil.com \
--cc=driver@jpl.nasa.gov \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.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 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).