Add API to kernel image
anhvuitinh
I am new to LynxOS and using version 5.0.
I have some APIs that I want to add to my kernel image (.KDI file) and
make it visible to user app.
How can I archieve this?
Thanks,
Peter
Steve Watt
There are a huge number of choices, just like in any operating system.
These are roughly in order of ease of implementation.
Write a library, supply it to the application writers, have them
link with it. Nothing added to the KDI. After all, the application
needs to know to call the functions, no?
For something a little more dynamic, there's dlopen() and friends.
If it's really kernel code (depends on what you're trying to do,
but kernel code isn't needed that often), device drivers are the
next most popular. The application opens something in /dev, and
makes read/write calls. If that's not an appropriate interaction
mechanism, try ioctl(). Device drivers are good because they
can be dynamically loaded and unloaded during testing.
Kernel modules are next... Don't know what the status of
those are in 5.0, but you can probably add system calls that
way. But you still need an application-side piece that knows
the system call number and parameters.
Just remember that the application needs to know to call your
API, and that usually requires modifying the application code
somehow. So stick to easiest (user library) unless you have
good, compelling, reasons to do otherwise.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...
anhvuitinh
To be more specific, I have one BIT API (get_bit_result( ) ) that I
need to make it available for user app to call to get the bit result.
Also, I have another bit_main() routine I have to start automatically
in the kernel when it is up to run bit tests and prepare the bit
report for the user app. The bit report is simply a global data
structure or just a global int that I need to make it visible to user
app.
I did make a shared library and link to my user app. The problem is
this shared lib has bit_main() included and I don't know how to make
it starts automatically when the shell is up. I guess I have to
include this shared lib in my kernel image as well, right.
Any help is appreciated. Thanks.
Peter
On Jul 30, 12:54 pm, Steve Watt <steve.removet...@Watt.COM> wrote:
> In article <70a07fc5-6955-435d-9096-6ee69f0b9...@y28g2000prd.googlegroups.com>,
Steve Watt
anhvuitinh <peter...@gmail.com> wrote:
[ Please don't top post, and trim replied text down to what you're actually
replying to. ]
>On Jul 30, 12:54�pm, Steve Watt <steve.removet...@Watt.COM> wrote:
>> In article <70a07fc5-6955-435d-9096-6ee69f0b9...@y28g2000prd.googlegroups.com>,
>>
>> anhvuitinh �<peter.m...@gmail.com> wrote:
>> >I am new to LynxOS and using version 5.0.
>> >I have some APIs that I want to add to my kernel image (.KDI file) and
>> >make it visible to user app.
>> >How can I archieve this?
>>
>> There are a huge number of choices, just like in any operating system.
>> These are roughly in order of ease of implementation.
[ ... ]
>To be more specific, I have one BIT API (get_bit_result( ) ) that I
>need to make it available for user app to call to get the bit result.
>Also, I have another bit_main() routine I have to start automatically
>in the kernel when it is up to run bit tests and prepare the bit
>report for the user app. The bit report is simply a global data
>structure or just a global int that I need to make it visible to user
>app.
>
>I did make a shared library and link to my user app. The problem is
>this shared lib has bit_main() included and I don't know how to make
>it starts automatically when the shell is up. I guess I have to
>include this shared lib in my kernel image as well, right.
OK, you don't need any kernel interaction for this at all that I
can see. Two simple architecture choices:
1. Have bit_get_result() do a pthread_once() call that runs bit_main().
2. Start a process at system initialization that does the bit_main()
thing and publishes the results (if it's ongoing, keeping them
updated) into a file or shared memory segment.
Then, When get_bit_result() is called, it looks in the file or
shared memory segment and returns appropriate results.
Both are pretty simple, which one depends on how "global" you want the
whole bit_main() thing to be. If it's inside one process, use #1. If
it's system-wide, use #2.
Or perhaps I'm missing your problem, which is how to start a process
at system initialization. That's almost certainly changed since
I last looked, but probably has something to do with /init, /etc/rc,
/bin/rc, /etc/inittab, /etc/ttys, or something along that line. It
is probably mentioned in the KDI specfile.