On Mon, 2 May 2005, Mike Smith wrote:
>
> On May 2, 2005, at 7:36 AM, John Dalgliesh wrote:
> > On Sun, 1 May 2005, Mike Smith wrote:
> >> On Apr 30, 2005, at 6:57 AM, John Dalgliesh wrote:
> >> Please don't do this. Load your firmware as part of the kext and
> >> then drop it,
> >> or load it with a startup item, but please don't make any assumptions
> >> about
> >> the state of the filesystem inside your kext.
> >
> > So KUNCExecute is out too? It uses the filesystem. This just gets
> > better
> > and better.
>
> The entire KUNC* family of functions should be avoided when possible;
> they exist primarily as a sop to driver authors unwilling to
> structure their
> driver architecture naturally.
Hehe. Amazing the things that get into the kernel these days :) It's like
someone wants to make it easy for driver developers, and write common code
for them so they don't have to figure it out themselves!
> Since they're implemented using exactly the model I'm describing, the
> only real difference is that because they're hopelessly generic and
> restricted you get bad UE and poor customisation.
OK.
> > Maybe that is because there isn't a good solution to it yet? I know
> > that
> > on linux, drivers only stopped reading files in the kernel when the
> > hotplug system was introduced.
>
> How is this relevant, other than to demonstrate that despite the best
> efforts of the system developers, third parties will continue to ignore
> sensible advice?
Sorry, my sentence was totally unclear, although the 'third parties taking
the path of least resistance' was definitely part of my point.
The linux hotplug system includes the kernel function 'request_firmware',
which will read a pre-installed firmware file by name out of
/usr/lib/hotplug/firmware/ or some such location. I don't know if the
reading is done in the kernel or by a userspace daemon 'tho.
> > And I was only using APIs in ways that other parts of the kernel were.
>
> You're not part of the kernel; you're a third-party component. When
> changes are made to the kernel, it can be updated in lock-step.
OK, fine, I'm a 'dynamically loaded kernel extension' then like all the
other kexts. Not part of the kernel but living in its address space,
linked to it, and required to follow all of its rules.
> The only parts of the kernel that do file-level I/O are the ones that
> provide basal services.
Well, you can call anything in there basal by definition. But I'm sure if
the corefile dumper were written again now it would have to use a daemon
that received a big memory object.
> Otherwise, why does the system have
> inetd, cron, or the shell? After all, I'm sure the kernel could just
> launch
> services and interpret commands directly.
>
> There's a division of labour in the system; one part of that division
> is that you don't do anything in the kernel that can reasonably be
> done outside it.
Sure, if I didn't have to be in the kernel anyway then I wouldn't be there
believe me. But since I do need to be there to drive say a PCI card I may
as well save myself some work and only write one component.
Why don't you apply the same rules to IPC? There is a nice userspace API
for IPC, so why duplicate it in the kernel? Anything that needs to send a
complicated IPC message should live in userspace and communicate via
shared memory. And how about threads? There's stacks of great userspace
APIs for dealing with threads. If your driver wants to use multiple
threads, then don't put it in the kernel; make a userspace daemon to do
the threading stuff. I'm sure I can come up with others: C++-friendly heap
memory? The whole C++ libkern OSType container library? They have
equivalents in userspace.
Just because there is a good userspace API doesn't preclude the use of a
kernel KPI. If you have to live in the kernel anyway you may as well make
yourself comfortable.
A related question is: Why do file systems and network stacks need to be
in the kernel at all? Actually, I'm pretty sure that the answer is that
they don't; they're just in there for efficiency/convenience.
Of course, I realise you have to draw the line somewhere, or you'd be back
to the Mac OS 9 days. Please just see that the location of the line is
neither canonical nor obvious. The definition of what's possible and
permissible to do in the kernel varies between OS's ... and according to
the policy of the day.
> = Mike
{P^/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-drivers/email@hidden
This email sent to email@hidden
