I'm writing a small module in kernel space.
This module needs to read config info in user space.
Can the module access a shared memory set up in the user space by calling shmat()?
Thanks.

The kernel can access anything.

There are several ways that you can integrate your module into the rest of the system, depending on what it needs to do. Each of these techniques implies a different way of providing parameters to and from the kernel code.

Probably the most flexible approach is to define your module as a virtual-device. When the module is loaded into memory, it defines a device-node, which will appear in (say) the /dev subdirectory. User applications communicate with the code by opening the device and issuing read, write, or ioctl() calls to it.

The virtual-device strategy has many advantages: user-code can access it with ordinary calls; there's already some permission checking available (you can set the "owner" and the "chmod" bits); and there's a lot of kernel infrastructure at your disposal. In this case, the protocol would be that your programs must first open the device, then issue an initializing call to it (either a write or an ioctl), then proceed with other requests.

For other possibilities, consider the /proc or /sys facilities... unique to Linux and quite astonishing.

A third possibility would be a custom system-call. The problem here is that the chances of "interference" with other things, or compatibility problems with future code, are high. And, programs have to do special things to issue these calls whereas they can "read and write to a file" a dozen different ways.

Hi Sundialsvcs,
Thanks for the info.
I understand that I could implement an virtual device driver for the kernel module or adding a new system call for the user module to call to achieve what I want. These methods have been mentioned in almost every kernel book.
But I just want to know that if shared memory can be another way (may not be a good way) for a kernel module to access info in user space.
Somehow the doc of shmat() never mentions if it can be called from kernel space.
Thanks again.

No, shmat() is a system call, designed to be used by a user-mode process. (Or, I presume, a kernel thread.)

A shared-memory object is certainly something that can be used as a communication area between oneself and the kernel. But it seems to me that it's something that a user process would allocate and somehow use in a particular system-call.

One of the things that's sorta keeping me in the dark here is that you really haven't explained what you're trying to do. What this kernel-module of yours is supposed to do and for whom.

"The kernel" really has two different aspects to its personality. One is non-moving: it's a collection of very privileged subroutines. The other is moving: a set of kernel-level threads which operate asynchronously in kernel-space to perform tasks like paging. The existing "read/write/ioctl to a file" metaphor is used a lot in Linux, e.g. /proc, /sys. But you don't usually see the kernel grabbing a user-available object, because that would make the implementation of that object quite tricky.

One possibility that you might look into for ideas is the "event" mechanism that's used, say, by hotplug or udev, where the kernel-level code communicates with a process by means of a write-only virtual file. This puts most of the "real work" into the hands of a root-privileged but otherwise-ordinary user mode process.

awang,

kernel space and user space are __meant__ to be separated, so if you're looking to access a specific program's mem, then you're best off trying to implement it as much as possible in kernel space, not user. Overlap between the two is __NOT__ encouraged - potential problems GALORE.

really, the kernel shouldn't deal with app memory, and the apps shouldn't deal with kernel memory. The only times when you'd want to make exceptions would have to be some pretty exotic applications. If you think it's one of those cases, I'd like to hear more about it.

Our application is handling TCP connections.
User would config policy for different TCP connections.
These policies are needed for a number of user processes. Therefore, a shared
memory is created to share the policy table for all user processes.
Only one process writes to the table the rest are read only from the table.

Now, In the net filter module in the kernel we add a piece of code to check and handle all the incoming TCP traffic against the configured policies.
Since we don't want to duplicated the policy table we could keep the table in kernel and use a system call for user processes to access it.
But the table is big and quite dynamic ie. add, delete, sort and search.
Also there is priority and other constraint associated with the policies.
therefore, sequential search is used.
With these constraints, it is not a good idea to implement the table in the kernel space.

So if net filter can access (read only) the table in the shared memory then our work can be much simplified.