Date: Tue, 27 Jan 1998 00:37:51 -0600 (CST) From: Joel Ray Holveck <joelh@gnu.org> To: mike@smith.net.au Cc: dag-erli@ifi.uio.no, hackers@FreeBSD.ORG Subject: Re: File I/O in kernel land (was: Re: 2nd warning: 2.2.6 BETA begins in 10 days!) Message-ID: <199801270637.AAA04478@detlev.UUCP> In-Reply-To: <199801270535.QAA01668@word.smith.net.au> (message from Mike Smith on Tue, 27 Jan 1998 16:05:30 %2B1030) References: <199801270535.QAA01668@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> I'd like to have the logo as a separate file rather than compile it >>>> into the lkm, but I haven't had much luck finding out how to do file >>>> I/O in kernel land. >>> It's extremely tedious. You'd be better off adding an ioctl hook to >>> the screensaver module and adding an extra console ioctl to pass >>> commands to the screensaver. >> I must be missing something here. What would be sending the commands, >> so that he gets the logo file? > Whatever he was planning to use to send the filename to the saver so > that it can find it in the first place. I must still be misunderstanding you. Would the program send the kernel the bitmap? The kernel would then have to bring it into the kernel's space, though, wouldn't it? This would mean dynamically allocating a (potentially large) chunk of the precious kernel memory. I personally would shy away from holding dynamic memory when it's not being used most of the time, preferring to bring in the bits on-demand if possible. > In my current dlopen() mania, I would be inclined to add some extra > functions to the saver module such that you could hook it into > vidcontrol and have it talk to itself. > ie. after you load "bitmap_saver.o" into the kernel, you'd run > something like: > # vidcontrol -x bitmap "add 10 image.gif" > which would load the bitmap_saver object into vidcontrol, look for the > saver_ioctl_call function and pass it the command string. Okay, so you mean the bitmap_saver object is loaded, the ioctl function parses the command and loads the file in userland, and then... what? Send an ioctl to stdout with the bits? If the bitmap is a fixed size, and statically allocated in the kernel, it can go ahead and fill it directly (although there would be a locking problem involved). My real concern is holding on to lots of dynamically allocated kernel memory, which is something I can't see getting around without the screen saver doing file I/O. In Linux, dynamic kernel memory was a precious resource. Is it not so in FreeBSD? Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801270637.AAA04478>