From: Pete <pete@putzin.net>
To: Arne Henrichsen <ahenric@yahoo.com>
Cc: "Randy.Dunlap" <rddunlap@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: sys_sem* undefined
Date: Sat, 04 Sep 2004 22:51:44 -0500 [thread overview]
Message-ID: <413A8D50.1040304@putzin.net> (raw)
In-Reply-To: <20040827092605.63433.qmail@web41504.mail.yahoo.com>
Arne Henrichsen wrote:
>>From an application (userspace) or from inside the
>>kernel?
>>
>>
>
>I need to do the syscalls from kernel space. Basically
>I am porting our custom vxWorks driver to Linux. We
>want to basically keep the structure of the vxWorks
>driver the same, so I am porting the individual
>vxWorks functions such as semBcreate, semGive etc.
>Thats why I want to use the SysV IPC semaphores, as
>they seem to most closely resemble the vxWorks ones. I
>know that there are much better ways of writing a
>driver, but that wouldn't fit in with the currect
>structure we have at the moment.
>
>Now if I want to call lets say sys_semget() from
>kernel space, must I use the _syscall3() function? I
>saw some people using this.
>
>Thanks for the help.
>Arne
>
>
>
>
>
Speaking as someone who has traveled down this road previously, I would
suggest that you re-engineer your driver instead of going with your
current plan. I realize that you think this would be quicker and easier,
but the maintenance headaches are pretty heavy as you get further into
this. Doing a driver the "right" way to fit the kernel makes sense
because it becomes very easy to maintain, whereas your method will
require much more work for changes to kernel versions, or changes to
core logic. I'm guessing the driver is pretty mature at this point, but
you still live with maintaining with the kernel.
As a side note, there are a lot of things that you might assume should
be a driver because that's sort of how it works in the VxWorks system,
but may map just as well to userspace, or some combo of userspace and
kernel space. Essentially, all software in VxWorks is part of the
kernel, so it's easy to just assume that what you are doing must be in
the kernel as well. Again, I've been working on a project for 5+ years
that was 3+ years of VxWorks, and is now migrating to Linux. I had to go
through a lot of this stuff as well.
Basically, I'm saying that there are better ways to do what you want to
do, but it's gonna involve some more up front work for you. I'd be
willing to chat more about this if you feel the urge off the list.
Pete Buelow
prev parent reply other threads:[~2004-09-05 3:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-25 11:50 sys_sem* undefined Arne Henrichsen
2004-08-25 16:14 ` Randy.Dunlap
2004-08-26 9:05 ` Arne Henrichsen
2004-08-26 14:08 ` Paulo Marques
2004-08-26 13:44 ` Arne Henrichsen
2004-08-26 16:28 ` Randy.Dunlap
2004-08-27 9:26 ` Arne Henrichsen
2004-09-05 3:51 ` Pete [this message]
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=413A8D50.1040304@putzin.net \
--to=pete@putzin.net \
--cc=ahenric@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rddunlap@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox