In Linux user space programming, we use RPCGEN for RPC programming. In Linux Kernel module, is there any interface like RPCGEN for programming?
NFS client (and server as well) is kernel-based and NFS protocol is based on Sun RPC, so have a look at it's implementation.
Related
I have several Linux applications which uses sockets (UDP/TCP IP).
I want (need, no matter why) to secure the connection with my own secure protocol without changing those applications.
I thought about changing the Linux kernel socket implementation, so I can use my secure protocol sockets, without changing those applications.
So, Is it possible to change the Linux kernel sockets, so when using send or receive sockets function, the inner Linux implementation will by mine ?
And how can I do it ? which kernel module do I need to change ?
I have a fairly large PCIe driver written on/for Linux, now I need to port it on FreeBSD. I don't yet know the BSD version, but I think at this point it's irrelevant, as I'd like to understand in general what major items will have to be modified during the porting efforts.
The good thing is that the driver is partitioned into OS independent "library" layer (OSI) and OS dependent, so it already has a "framework" permitting to port it on other OS-es, and I hope most of the efforts will be focused on OSI side. So far I see the following big chunks of work:
init code, i.e. the OS-specific code that "plugs" the driver into
system (similar to what init_module, cleanup_module does in Linux)
code registering driver in a PCI core subsystem of the kernel
character driver registration code 4) DMA operations
What else should I be paying attention to? This driver is a device doing hardware encryption, so it is offload device (ingress packets from NIC enter system normally and then diverted to the device).
If there are useful web links to description of BSD drivers development/porting (similar to LDD), I'd happily accept it :)
In 2011, Jeff Roberson (and later Mellanox) added some shims to ease porting Linux drivers, which makes most of the code be used as-is, when he ported the Linux InfiniBand drivers to FreeBSD. So, assuming I am some newcomer from Linux driver development world, I'd start by looking at:
https://svnweb.freebsd.org/base/head/sys/ofed/include/linux/
Where you would find implementations of many required Linux driver API and their FreeBSD native counterpart.
There is another quickstart document by John-Mark, here, helpful for those who are already familiar with driver writing.
If you would prefer starting from the beginning, I think the FreeBSD Architecture Handbook would be an useful start point.
Additionally, there is a book by Kirk McKusick, Robert Watson and George Neville-Neil, titled "The Design and Implementation of the FreeBSD Operating System", the latest version at this time is 2nd edition, and the chapter 8 detailed device drivers.
Most device drivers are merely wrappers of hardware operation to fit OS interfaces, so a well layered driver should be relatively easy to port nowadays.
If you have questions, or is a vendor of hardware, you can also join various FreeBSD mailing lists (freebsd-drivers#, etc.).
This might be a stupid question but I am confused and google couldn't help.
I know Linux is the Kernel which is the heart of many distros( Ubuntu, Mint). But when we say "Linux kernel programming", what do we exactly mean? Is it Bash scripting?
And how it is related to the device driver development? (Do we mean that the hardware is running linux kernel and we do kernel programming to support peripherals, this is ,in general, device driver development in relation to linux? )
Linux Kernel Programming is something which involves kernel components, meaning - kernel data structures and headers. A program in which one uses the existing kernel features or enhances the current features is a kernel program, typically a kernel module. In a way even the Bash scripting can be called as Linux Kernel programming. The device driver in a broad term is nothing but a set of interrupt handlers. Having said that, a device driver is a kernel program in itself as it uses the Linux kernel capabilities which is ported on a device/hardware. So in short the relation between the two is Device driver development is a form of Linux Kernel Programming.
Basically you have two kinds of programs running on your computer : the kernel, which has access to the computer hardware, and "userland" programs which ask the kernel to do low-level stuff (allocate memory, send data to the network, ...).
To do this, the kernel must know how to interact with some given piece of hardware. This is what we call "device drivers". In Linux, the device drivers are implemented as kernel module and device driver programming is akin to kernel programming because you deal with low-level operations straight to the metal instead of higher-level operations that go through the kernel.
Bash scripting is programming a shell (Bash) to run userland programs that themselves use the kernel to do the actual work. Bash-scripting is userland programming.
Device driver development is a subset of Linux kernel programming.
Device driver development is writing or modifying kernel modules that will handle a device. A device driver is a special case of kernel modules.
Kernel modules are codes that work from within the kernel and do privileged tasks.
Kernel modules are an integral part of Linux kernel programming. That is how device driver development and Linux kernel programming are related. The former is a part of the latter.
Also, device drivers will ultimately be inserted into the kernel, and will work in a kernel context. That is, device drivers ultimately become a part of the kernel.
Hence driver development is a subset within Linux kernel programming.
I am trying to implement a RPC mechanism in an embedded SoC. The SoC has a dual-core cortexA9, with one core running ThreadX and the other running Linux 3.8.
My question is:
Is Sunrpc a good choice for this?
As far as I know, sunrpc on Linux only supports UDP/TCP transport. Is it possible to add a proprietary transport? Is so, do I have to hack both user-space and kernel code?
Thanks
Joey
I am using Linux SCTP Stack. Currently on the same Linux machine I need to deploy a process which uses non OS SCTP STACK. (i.e. it opens a RAW socket and then handles transport level message on its own).
When SCTP Init comes Linux gives the packet to both processes.
Can this be avoided?
I don't want Linux SCTP to handle message which are not used by it. (used by other Non OS SCTP Stack)
Is this possible?
More generally when faced with this kind of issue there are three options:
1) Stop the Linux SCTP module from being loaded at boot time (Note: it cant be unloaded at run time) and just use the non-OS implementation.
2) Some how preconfigure each SCTP implementation to know which associations it owns and to ignore messages for others.
3) Port the non-OS system to use the Linux implementation.
Any actively supported Linux system using SCTP is going to have issues if it does not offer the third option.
Note: If you are using the Dialogic Non-OS SCTP implementation on Linux then you can easily switch to using their OS wrapped version 'SCTPN'.
Regards
This may not be an option, but having the non-lksctp process use UDP tunnelling of SCTP works very well for us. The (commercial) stack we use is configurable for SCTP over UDP, or SCTP over IP (with raw sockets, like you).