public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rodolfo Giometti <giometti@enneenne.com>
To: linux-kernel@vger.kernel.org
Cc: linuxpps@ml.enneenne.com, akpm@linux-foundation.org
Subject: [RFC] PPS: Implementing LinuxPPS API with new syscalls
Date: Tue, 5 Jun 2007 09:25:01 +0200	[thread overview]
Message-ID: <20070605072501.GA15273@enneenne.com> (raw)

Hello,

after a little studing on new generic netlink interface and some
letters with Andrew Morton I decided to drop using the netlink API at
all and start using new specific syscalls.

Looking at current LinuxPPS API and at RFC2783 I think we need the
following syscalls:

   asmlinkage long sys_time_pps_find(int cmd, int __user *source,
                                          char __user *name, int namelen,
                                          char __user *path, int pathlen);
   asmlinkage long sys_time_pps_getparams(int source,
                                          struct pps_params __user *params);
   asmlinkage long sys_time_pps_setparams(int source,
                                          const struct pps_params __user *params);
   asmlinkage long sys_time_pps_getcap(int source, int __user *mode);
   asmlinkage long sys_time_pps_fetch(int source, const int tsformat,
                                          struct pps_info __user *info,
                                          const struct timespec __user *timeout);

In fact:

* the two LinuxPPS functions time_pps_findsource() and
time_pps_findpath() can be implemented with sys_time_pps_find()
specifying proper finding command into "cmd",

* the RFC2783 time_pps_create() and time_pps_destroy() are not needed
since no PPS sources are created or destryed from userspace. The former
can be simply implemented as follow:

   static int time_pps_create(int source, pps_handle_t *handle)
   {
           /* In LinuxPPS there are no differences between a PPS source and
            * a PPS handle so we return the same value. */
           *handle = source;
    
           return 0;
   }

while the latter is just a "return 0".

* the RFC2783 time_pps_kcbind() is not implemented into Linux so it is
just a "return -EOPNOTSUPP".

Also using syscalls the problem regarding the pps_handle_t type
disappears, even if the needed of using time_pps_findsource() or
time_pps_findpath() still remains.

Regarding the file timepps.h I think I should reintroduce it into the
kernel header files since it's needed to define new PPS types and new
syscalls wrappers for RFC2783 compatibility.

Comments? Suggestions? :)

Thanks a lot,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@enneenne.com
Linux Device Driver                             giometti@gnudd.com
Embedded Systems                     		giometti@linux.it
UNIX programming                     phone:     +39 349 2432127

             reply	other threads:[~2007-06-05  7:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-05  7:25 Rodolfo Giometti [this message]
2007-06-06 20:29 ` [RFC] PPS: Implementing LinuxPPS API with new syscalls Andrew Morton
2007-06-06 21:24   ` Rodolfo Giometti
2007-06-07 10:14     ` Rodolfo Giometti

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=20070605072501.GA15273@enneenne.com \
    --to=giometti@enneenne.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxpps@ml.enneenne.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