On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
>
> Fair enough, but I think the code could become a trifle simpler/easier
> after the conversion, so probably greater chances of getting merged :-)
I see. I'll start thinging about it.
> But that's alright -- see, as I said, you're confusing between the
> "special device" that represents the *PPS source* itself, with the port
> or device that it uses to *physically* connect to the PC.
>
> In the RFC, when they say that the userspace app must open(2) the PPS
> source (as they have illustrated in the example too), they mean that
> it open(2)'s the special device/file associated with the PPS source,
> and *not* the /dev/lpXXX or /dev/ttySXXX that it might be connected
> through physically.
>
> So they mean something like /dev/pps0, /dev/pps1 etc instead. Of course,
> no such special device exists on a Linux box already, but that's fine
> and obvious! *You* are supposed to create / instantiate that when a
> pps_register_source() is done from some in-kernel subsystem.
So your are proposing to create a char device interface then using
syscalls one? In this case how do you manage the case where your GPS
antenna and PPS source are both connected with the serial port
(i.e. /dev/ttyS0)?
Currently the RFC says to you that you should open the serial port:
fd = open("/dev/ttyS0", ...);
and the passing its filedes to pps_time_create() in order to get the
corresponding PPS source handler:
pps_time_create(fd, &handler);
As you propose you need _two_ open() and not just one... and even if
you decide to open the /dev/ppsX inside the pps_time_create(), how do
you recognise _which_ /dev/ppsX is connected with filedse "fd"?
I quite sure that RFC is broken since it doesn't take in account that
a PPS source maybe not connected with any cahr device at all. I tried
to explain this problem to RFC's gurus but they never answered to me,
so I decided to resolve the problem by myself. ;)
> As I said, it's not the char device for the physical interface itself
> being discussed there. That could be parport, uart, some arbit GPIO pin
> whatever. But whenever the corresponding kernel subsystem does a
> register_source(), you could create the /dev/ppsXXX device ...
Ok, but in this case you still are _not_ RFC compliant (as showed
above). You need that users give to you _two_ devices (the serial line
and the PPS source), meanwhile, for the RFC, you just need one. So no
differences from my solution from this point of view.
> Hmm, but that's a non-standard, not-mandated-by-RFC syscall. I don't see
> how you can get this merged, really :-)
They are not-mandated-by-RFC since simply RFC _is broken_! :)
I need them (or just one of them) in order to find a PPS source into
the system. Just as you need the second device name in your solution
with char devices.
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: [email protected]
Linux Device Driver [email protected]
Embedded Systems [email protected]
UNIX programming phone: +39 349 2432127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
