Re: Using OSKextRequestResouce from kext init routine?
Re: Using OSKextRequestResouce from kext init routine?
- Subject: Re: Using OSKextRequestResouce from kext init routine?
- From: Ken Hornstein <email@hidden>
- Date: Fri, 14 May 2010 21:52:45 -0400
>There should be headerdoc for the function, but I just tried to search
>for in Xcode and got zilch. The comments are in the header, though.
Right, I read those. But it's a little ... sparse? I mean, yeah,
I worked out how to call it, but some of the details are a little
vague. And I did read the release notes that mentioned this function
so I understand why it was put into place ... and that I'm abusing
it.
>If you have a BSD kext that requirest a single moderately-sized resource
>to start, it isn't so bad to just include the data in your executable.
Sigh. If only it was that simple.
I'm in a weird spot. I'm porting a Linux network filesystem to
MacOS X. Yes, that is almost insane as it sounds. I actually have
something working, but I'm going back and cleaning up some of the
details that I skipped. One of those details is that the modules
that make up this filesystem make use of the Linux kernel module
parameter feature, where you can declare module parameters in your
source code and then set those parameters in files in /etc/modprobe.d.
I will spare everyone the details of how that's actually implemented
in Linux; suffice it to say that my solution involves a perl script
that processes all of the source files.
Now, I've read the archives, and I understand that everyone is
saying that you should _not_ have a preferences file for kexts; a
userspace program should set those parameters at startup time,
probably via sysctl. But ... one of my goals is to actually get
these changes push back into the original source tree. If those
changes involve restructuring whole piles of the original source
code ... well, the chances of those changes actually making it
back in would be approximately nil. (It's not that the authors of
the filesystem in question don't care about portability; they've
made some strides in the portability department, but the more complex
the change, the harder it is to get it pushed into their tree).
So, I'm kinda stuck when it comes to large restructuring; if MacOS X
does something a whole lot different than Linux, it's my job to make
it damn well work with the minimum changes possible to the core code.
And to top it all off, there is a bunch of initialization that
happens at module startup time; some of the initialization depends
on key options that need to be set before the initialization routines
get run (some options can be set at runtime, and I already support
sysctl access for those). Obviously I have reasonable defaults, but
sometimes those aren't good enough. If I was writing this from scratch,
yeah, it would be done completely differently ... but that simply
isn't in the cards.
It occurs to me, though, that maybe I'm making this harder than I need
to. I mean, I could simply call the appropriate vnode routines to read in
the file and parse it myself. In a perfect world I could parse a prefs
XML file from the kernel (or have it parsed for me by a userspace daemon),
but somehow I don't see that happening anytime soon :-/
--Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden