[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070630170653.GS13886@enneenne.com>
Date: Sat, 30 Jun 2007 19:06:53 +0200
From: Rodolfo Giometti <giometti@...eenne.com>
To: Christoph Hellwig <hch@...radead.org>,
David Woodhouse <dwmw2@...radead.org>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] LinuxPPS (with new syscalls API) - new version
On Sat, Jun 30, 2007 at 09:38:27AM +0100, Christoph Hellwig wrote:
>
> Sorry for coming in that late, but using syscalls for something as
> periphal sounds like a very bad idea to me, and the syscalls aren't
> defined nicely either (e.g. you have an ioctl lookalike). I'd say
> back to the drawingboard.
PPS API is not only a periphal class. RFC 2783 defines new «functions»
that allow accesso to internal system data collected by some
periferals but these devices are never managed as a tipical char or
block device.
I think implementing parts or full RFC 2783 PPS's functions as
syscalls are not so wrong... IMHO, at least! :)
> And yes, even ioctls are nicer than badly designed syscalls :)
I see, but consider that some PPS devices cannot be always connected
with a filedescriptor since, for example, some PPS devices are
connected by serial lines, other by parallel ports and other
(expecially on embedded systems) are connected by CPU's GPIOs.
An userland programs shouldn't know whenever these devices are
connected, they should only know how to collect PPS data from the
system.
> Also code seems to be odd at least in a few places, e.g. all the access_oks
> and double checks of the ioctl-lookalike commands should go.
I already removed such functions in my latest patches. :)
Thanks,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@...eenne.com
Linux Device Driver giometti@...dd.com
Embedded Systems giometti@...ux.it
UNIX programming phone: +39 349 2432127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists