All of lore.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 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.