Date: Wed, 31 Jul 2002 18:30:57 +0200 From: Daniel Lundqvist <daniel@malarhojden.nu> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@freebsd.org Subject: Re: select()/poll() i kernel. Message-ID: <20020731163057.GB72029@malarhojden.nu> In-Reply-To: <3D471152.4347ABD1@mindspring.com> References: <20020730152514.GA66448@malarhojden.nu> <3D471152.4347ABD1@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 30, 2002 at 03:21:06PM -0700, Terry Lambert wrote:
> Daniel Lundqvist wrote:
> > I was wondering if there is a select()/poll() for use in kernel by
> > kernel threads? I've been looking around in sys/kern/ but didn't find anything.
> > I'm currently developing under 4.6.
> >
> > Please CC me since I'm not a member of the list.
>
> 4.6 does not have kernel threads; it has kernel processes (kproc's),
> however, which are just standard processes which have been assumed
> to have entered the kernel. As such, they are suitable for use as a
> context for blocking operations (you can only sleep things that have
> the ability to have scheduler queue entries, and therefore be awakened
> at a later time).
>
> There is no explicit support for a "select" call; most operations on
> file descriptors assume a process context in user space from which
> parameters can be copied, and results copied out.
>
> Rather than correcting the FreeBSD model to internally add a space
> identifier parameter to the body of the call, and make the system
> calls call that, instead of being directly wired in, you have two
> real options:
>
> 1) Use "The mmap trick" to obtain memory in the user space
> portion of the kproc address space, so that when uiomove
> and/or copyin/copyout operate, they have someplace to get
> or put the data.
>
> 2) Write the moral equivalent of the select(2) (or poll(2))
> code that can be called from kernel space, and call it
> from your kproc.
>
> Note that either of these will *only* work from a kproc, where the
> current process identfier is the kproc. So you can't use them in
> fault handlers or interrupt handlers, if that's what yu are thinking.
>
> Really, FreeBSD needs a better abstraction of the file I/O and other
> operations in kernel space, so that doing this type of work is much
> easier.
>
> On the other hand... it's likely that your expectations of how a
> kproc can be used as if it were a kernel thread are unreasonable,
> so maybe it's just as well that there is not explicit support for
> this kind of thing, like there is in Linux, AIX, and Solaris.
OK... maybe if I describe what I want to do someone might have a better
solution.
Basically I have an kernel module that should act as a filter
towars clients running in user space. The clients will tell the module
what kind of messages it's intrested in. It will be used as a messaging
bus running over multicast. This is just to test a couple of ideas
of mine. If it doesn't work I'll have to come up with something new :)
This is what the kernel module will do:
* Bind up an UDP socket on INADDR_ANY and joins an multicast group
* Register a character device /dev/ih
* Distribute incoming message to all interested applications
* Send out messages from applications
A client will then open /dev/ih and run a couple of ioctls to tell the module
which messages it want. Using the filedescriptor returned from the open it
should be able to read()/write() like on any other descriptor.
The kernel module will keep a list of applications using it and will
distribute incoming messages to all interested applications. It will also
take care of writes to /dev/ih and send them out on the UDP socket.
If there is no kernel select()/poll() I see no other way to write the kproc
function as follows:
void kproc (void) {
init;
while(running) {
check UDP socket;
for all applications
check for writes;
sleep();
}
}
If anyone has a better solution to this I'm all ears.
Kind regards,
Daniel Lundqvist
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020731163057.GB72029>