Re: Running Linux kernel modules.
* Andrew Gallatin [EMAIL PROTECTED] [010111 20:13] wrote: On Thursday, January 11, 2001 3:12 PM, Alfred Perlstein [SMTP:[EMAIL PROTECTED]] wrote: * Carl Makin [EMAIL PROTECTED] [010111 14:52] wrote: There are a couple of linux kernel modules that I'd love to run under FreeBSD. I've always assumed that I'd have to rewrite them substantially to make that happen. Can anyone give me some pointers on how hard it could be to port a linux kernel module to FreeBSD? Depends on how familiar you are with kernel internals, for instance after taking a quick look at the kernel module needed to run vmware it was pretty clear that someone with the experience and time could have it done in under a week, about 2 weeks later some maniac ( :) ) surfaced who had done just that. The biggest problem I've had porting linux drivers is that linux exports enough internals to allow drivers to distinguish between multiple opens of the same device. Eg: [snip] Isn't this gross? Is there a better way? Beyond gross. :) I've heard of many requests for this special functionality in FreeBSD, things as you've mentioned (vmware, your driver) as well as ptys. If you wanted to fix our interface I'd be glad to help review it and assist if possible. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Running Linux kernel modules.
Andrew Gallatin wrote: To handle the multiple open problem, I'm overloading the open and close system calls. Upon open, I call the native open, then I grovel around in the process' open file table looking for my special file. When I find it, I mark fp-f_nextread with a magic number, then store a pointer to the per-open private data in fp-f_offset. On close, I go grovelling again. I deallocate the private data, clear the magic number, and call the system close function. I've also got an at_exit() hook that does much the same thing. Obtaining the file descripter at ioctl() and mmap() time is much more interesting. When I'm called from a syscall, I pull the args out of the process and grab the fd, index the process' file table and bingo. The real problem is when mmap is called out of a fault (and not dev_pager_alloc, which is what gets called when the mmap syscall is issued). Right now I throw up my hands and return the private data from the first instance I find when walking the process' open file table. If this becomes a problem, I'm planning on prefaulting the pages at dev_pager_alloc() time (when I can get an fd from the process) and wiring them -- its only 20k per process.. Isn't this gross? Is there a better way? I think that the better way is to actually have each open have a different minor number. i.e. each process opens a different copy. The way to achieve this best is with cloning devices. apply within phk for more info :-) I could imagine however that you could assume that each process opens the device only once, and thus have a hash-table of private info, keyed on curproc. You should be able to store the curproc key with the request currently being serviced so that teh interrupt routines can also use the same key. Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Running Linux kernel modules.
Julian Elischer writes: Isn't this gross? Is there a better way? I think that the better way is to actually have each open have a different minor number. i.e. each process opens a different copy. The way to achieve this best is with cloning devices. apply within phk for more info :-) Does this mean that the processes can open /dev/foo0 twice and the driver sees a different minor number for each open? Or does it mean that the process has to open /dev/foo0 and /dev/foo1? If the former, that's awesome!... How do I use it? If the latter, then it isn't practical for things like vmware and my Giganet VI driver because both depend on closed-source userland code which cannot be taught to open differently named special files. I could imagine however that you could assume that each process opens the device only once, and thus have a hash-table of private info, keyed on curproc. You should be able to store the curproc key with the request currently being serviced so that teh interrupt routines can also use the same key. It would simplifly things, but I don't think that this is going to be a valid assumption in general.. Thanks! Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Running Linux kernel modules.
:To handle the multiple open problem, I'm overloading the open and :close system calls. Upon open, I call the native open, then I grovel :around in the process' open file table looking for my special file. :When I find it, I mark fp-f_nextread with a magic number, then store :a pointer to the per-open private data in fp-f_offset. On close, I :go grovelling again. I deallocate the private data, clear the magic :number, and call the system close function. I've also got an :at_exit() hook that does much the same thing. Wait a sec... f_nextread and f_offset can be messed around with by the user process, what prevents the user process from screwing up your kernel data pointer? Why not just track the opens independantly in the overloading code? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Running Linux kernel modules.
* Andrew Gallatin [EMAIL PROTECTED] [010112 15:29] wrote: Julian Elischer writes: Isn't this gross? Is there a better way? I think that the better way is to actually have each open have a different minor number. i.e. each process opens a different copy. The way to achieve this best is with cloning devices. apply within phk for more info :-) Does this mean that the processes can open /dev/foo0 twice and the driver sees a different minor number for each open? Or does it mean that the process has to open /dev/foo0 and /dev/foo1? If the former, that's awesome!... How do I use it? Well you have to write it, but you basically have the open(2) syscall path optionally return a seperate void * 'cookie' that you must pass into all operations (fileops) on that file. It's not a major rewrite of any code, you just need an extra parameter per fileop and store it in the struct file. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Running Linux kernel modules.
Matt Dillon writes: :To handle the multiple open problem, I'm overloading the open and :close system calls. Upon open, I call the native open, then I grovel :around in the process' open file table looking for my special file. :When I find it, I mark fp-f_nextread with a magic number, then store :a pointer to the per-open private data in fp-f_offset. On close, I :go grovelling again. I deallocate the private data, clear the magic :number, and call the system close function. I've also got an :at_exit() hook that does much the same thing. Wait a sec... f_nextread and f_offset can be messed around with by the user process, what prevents the user process from screwing up your kernel data pointer? Pure ignorance. Since the device doesn't support reads/writes, I'm hoping nobody will try to lseek on it ;) I could overload the syscalls that touch these fields if I have to, but I'm hoping this will be just an interum hack and don't want to waste time polishing it. Why not just track the opens independantly in the overloading code? I'm not sure I know what you mean. I don't just need to track multiple open/closes, I need to be able to hang a pointer off of something that I can get at durning an mmap() or ioctl() syscall so that I can tell which instance I'm dealing with. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Running Linux kernel modules.
: : Why not just track the opens independantly in the overloading code? : :I'm not sure I know what you mean. I don't just need to track :multiple open/closes, I need to be able to hang a pointer off of :something that I can get at durning an mmap() or ioctl() syscall so :that I can tell which instance I'm dealing with. : :Drew f_data? Or if f_data is a vnode, a field in the vnode ? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Running Linux kernel modules.
Is there a possibility of a generalized interface where any linux kernel module could be loaded, in the event that the linux emulator were loaded? Or would this require running the linux kernel in RAM, and therefore running two virtual machines? On Thursday, January 11, 2001 3:12 PM, Alfred Perlstein [SMTP:[EMAIL PROTECTED]] wrote: * Carl Makin [EMAIL PROTECTED] [010111 14:52] wrote: There are a couple of linux kernel modules that I'd love to run under FreeBSD. I've always assumed that I'd have to rewrite them substantially to make that happen. Can anyone give me some pointers on how hard it could be to port a linux kernel module to FreeBSD? Depends on how familiar you are with kernel internals, for instance after taking a quick look at the kernel module needed to run vmware it was pretty clear that someone with the experience and time could have it done in under a week, about 2 weeks later some maniac ( :) ) surfaced who had done just that. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message Glen M. Gross Unix Technical Support Specialist Symark Software 5716 Corsa Avenue, Suite 200 Westlake Village, CA 91362 http://www.symark.com [EMAIL PROTECTED] [EMAIL PROTECTED] Main: 800-234-9072 or 818-865-6100 Main fax: 818-889-1894 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Running Linux kernel modules.
On Thursday, January 11, 2001 3:12 PM, Alfred Perlstein
[SMTP:[EMAIL PROTECTED]] wrote:
* Carl Makin [EMAIL PROTECTED] [010111 14:52] wrote:
There are a couple of linux kernel modules that I'd love to run under
FreeBSD. I've always assumed that I'd have to rewrite them substantially
to make that happen.
Can anyone give me some pointers on how hard it could be to port a linux
kernel module to FreeBSD?
Depends on how familiar you are with kernel internals, for instance
after taking a quick look at the kernel module needed to run vmware
it was pretty clear that someone with the experience and time could
have it done in under a week, about 2 weeks later some maniac ( :) )
surfaced who had done just that.
The biggest problem I've had porting linux drivers is that linux
exports enough internals to allow drivers to distinguish between
multiple opens of the same device. Eg:
int
foo_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg)
{
foo_per_open_data *priv = filp-private_data;
foo_softc *sc = priv-dev;
..
}
AFAIK, there's no clean way to do this with FreeBSD. I think this is
why VMware is limited to running one virtual machine.
This can be somewhat overcome in a very ugly way -- At my day job, I'm
porting a driver for Giganet cLAN1000 VIA adapters. This has much
the same problem as VMware. They've got an open-source linux kernel
module and a closed source userland binary.
To handle the multiple open problem, I'm overloading the open and
close system calls. Upon open, I call the native open, then I grovel
around in the process' open file table looking for my special file.
When I find it, I mark fp-f_nextread with a magic number, then store
a pointer to the per-open private data in fp-f_offset. On close, I
go grovelling again. I deallocate the private data, clear the magic
number, and call the system close function. I've also got an
at_exit() hook that does much the same thing.
Obtaining the file descripter at ioctl() and mmap() time is much more
interesting. When I'm called from a syscall, I pull the args out of
the process and grab the fd, index the process' file table and bingo.
The real problem is when mmap is called out of a fault (and not
dev_pager_alloc, which is what gets called when the mmap syscall is
issued). Right now I throw up my hands and return the private data
from the first instance I find when walking the process' open file
table. If this becomes a problem, I'm planning on prefaulting the
pages at dev_pager_alloc() time (when I can get an fd from the
process) and wiring them -- its only 20k per process..
Isn't this gross? Is there a better way?
Drew
--
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science Phone: (919) 660-6590
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
