DragonFly kernel List (threaded) for 2008-05
Re: Anticipatory disk scheduling - soc 2008
:I thought of exactly the same thing (except I was not sure where to
:add this)since I assume that the scheduler which I write should be
:accessbile as an interface (hence add an API) rather than plugging it
:into the NATA driver. However this would require me to modify (would
:it?) calls in the nata code - is this OK?
Yes. In fact, it makes it easier because you can create a kernel option
for your scheduler and instead of replacing the NATA code you can
The way that works is you add your option name to
/usr/src/sys/conf/options and specify an option header file to include,
such as this:
Then in the NATA driver you do:
... calls to your API ...
... original nata queueing code ...
This allows people to select which scehduler they want to use when
they compile their kernel.
:> This would allow you to test your scheduler with a vkernel by also having
:> the VKD driver call it (/usr/src/sys/dev/virtual/disk).
:Im not sure of what I understand about the vkernel. Is this a common
:feature in BSD systems or only the DragonflyBSD? Could I have more
:information (or hyperlinks) to this and how it is important or can
:help me in testing my scheduler, as you mention above.
:Thanks for those tips!
'man vkernel' on a DragonFly box (e.g. on your leaf account). It is
specific to DragonFly. Other BSDs have to use a machine emulator.
Using a machine emulator works too, it just isn't as convenient.
Basically whenever you make major modifications to a kernel, simply
rebooting into that kernel can result in a very long development
cycle because any bug in your code is likely to crash the kernel (and
bugs in filesystem/block-device related code can result in a corrupt
disk, as well). So it is best to do all major testing of such code
in a virtual environment before trying it out on a kernel running on