All of lore.kernel.org
 help / color / mirror / Atom feed
From: viro@ZenIV.linux.org.uk
To: "David S. Miller" <davem@davemloft.net>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Kconfig fix (GEN_RTC dependencies)
Date: Tue, 6 Sep 2005 03:24:23 +0100	[thread overview]
Message-ID: <20050906022423.GT5155@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20050905.185141.44096788.davem@davemloft.net>

On Mon, Sep 05, 2005 at 06:51:41PM -0700, David S. Miller wrote:
> Admittedly, the whole RTC situation is quite a mess I have to
> agree.
> 
> To make the problem worse, we have two sets of RTC ioctls
> which userland makes use of on Sparc.  The older ones which
> the SBUS RTC driver exported and supported, and the normal
> ones the rest of the world uses.  Because the normal RTC driver
> gets used as well, userland actually tries both ioctl sets.
> Therefore, it probably would work to completely do away with
> the SBUS RTC ioctl support, and only use the normal ones.
> 
> This would make using the generic RTC driver much easier, I
> would think.

Yeah...  Note that what you've just called "generic RTC driver" is
*not* GEN_RTC; it's RTC.

>From my reading of that code, GEN_RTC should've been called FAKE_RTC...
AFAICS, more or less clean solution would be to split the damn thing
into frontend (parsing of ioctls, hopefully very few API variants) and
backend (set of methods for talking to real hardware, or, in this case,
fake of a hardware).  With at most one backend selectable (i.e. select
in Kconfig) and frontend available if backend is selected.  With any
luck we could eventually get frontends down to one; in any case, their
APIs have no place in include/asm-*

Note that e.g. fsckloads of MIPS RTC drivers would simply become backends
in that scheme; lots of duplicated glue would disappear from them...
I'll look into that once the things settle down a bit with handling the
-bird tree; if you get there first with the work you've mentioned above -
even better ;-)

  reply	other threads:[~2005-09-06  2:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-06  0:56 [PATCH] Kconfig fix (GEN_RTC dependencies) viro
2005-09-06  1:51 ` David S. Miller
2005-09-06  2:24   ` viro [this message]
2005-09-06 14:40     ` Maciej W. Rozycki
2005-09-06 17:48       ` Tom Rini
2005-09-07 18:06         ` Maciej W. Rozycki
2005-09-07 19:42           ` Tom Rini

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=20050906022423.GT5155@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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 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.