>>>>> "djm" == Darren J Moffat <darr...@opensolaris.org> writes:
djm> I'm not saying passing a list of names over the ioctl is
djm> impossible, more it just doesn't feel right to me at the
djm> moment - but I'm happy to be convinced otherwise.
im not sure I want to convince you otherwise. but here are two
attempts for considering:
1. When we were talking about 'zfs list' scalability and 'zfs destroy
<snapshot>' scalability with thousands of filesystems there was
also some discussion of time burned up making thousands of ioctls
to accomplish one administrative action. Maybe the ioctl
packing/unpacking/copyin overhead is part of the problem. Or maybe
there is actually work to be done in each of those thousand ioctl
so that combining them will be of no benefit, but making the
in-kernel work more efficient would probably be easier if it were
coalesced into fewer ioctls rather than many. sometihng that can
delete, insert, query multiple rows per operation like SQL, albeit
JUST multirow, without a parsed text grammar and without stuff like
'UPDATE' for supporting multiple writers, might *not* be overkill.
2. How is stuff like snapshot -r implemented atomically? Could a more
complicated ioctl interface make -r more elegant rather than less?
Maybe the ultimate question isn't ``should we pass an asston of
stuff in one ioctl''. The questions are more like:
* given this will probably not be the last atomic-change
needed---snapshot -r needed for consistency, this needed for
speed, and who-knows-what next?---which do you find less
maintainable:
(a) transactional ioctl interface, where you call ioctl
BEGINTRANSACTION, ioctl DOSTUFF ioctl DOSTUFF ioctl DOSTUFF,
ioctl COMMIT
(b) big ioctl interface where you express everything you want
done at once in one possibly-complicated large structured
ioctl blob and return success/fail on the whole blob
the (b) seems to be more in line with this nvlist hairy stuff
infesting solaris everywhere so maybe that's better?
* what would you find simpler / better-respecting kernel-userland
boundary?
(a) passing instructions in some rather ugly interpreted bytecode
language, ``0xC0 means RANGE opcode, arguments to follow in
8-bit registers,'' full of .h macros and lots of structs in
unions. kernel executes bytecode to expand full argument
list, then dostuff. (your current favored proposal)
(b) expand in userland in C or in bash, rather than in kernel
crappy-switch()-based-bytecode-interpreter, simply pass the
full argument list in the ioctl, copyin, dostuff.
I'm reminded of printers that kept advertising increasingly
complicated page-description languages because the parallel port
and LocalTalk were so slow that publishers wanted to express
their pages in as few bits as possible.
now, this is not the only reason said thing happened with
printers. The printer became a hardware dongle enforcing your
``authorized'' use of the fonts, which were encrypted in an
attempt to bind them to $complicatedlanguage---they never got
this far, but if it still existed would probably be enforcing
rules like ``you have to pay for the Professional version of the
font if you want to print more than two consecutive capital
letters. The Home font is only for normal home correspondence so
consecutive capitals will be downcased automatically.'' But the
former slow-interface-port reasons are how it was pitched, how
the architecture was justified.
People bought the argument. Printers grew hard drives to cache
fonts and reuseable ``preamble'' libraries written in
$complicatedlanguage, printer CPUs and RAM's bigger than the
computers driving them, and hidden cost of $complicatedlanguage
almost exceeded that of the publishing package driving it.
Sometimes you could see a page on the screen, but it was too
``complicated'' to print---solution: buy a bigger printer!
WYSIWYG broke since publishing package had to reimplement
$complicatedlanguage on screen, badly. merchants of
$complicatedlanguage, who are now a hegemonic monopoly, sneakily
trickle-sold heavily-DRM'd brokeass versions of
$complicaedlanguage for linking with the publishing packages to
make WYSIWYG work again like it used to, and these blobs even
made it into Solaris. all because of a fucking parallel port.
Eventually it was deemed mistaken and the whole damn tower
collapsed. $complicatedlanguage in solaris bitrotted. We
invented faster interfaces and stopped overcharging for them
(USB, Ethernet), and extremely simple page description languages:
modern laser printers get a single JBIG image of the page,
pre-dithered, and do not even understand what a glyph is. I am
not even sure how they decompress the JBIG, if they even have
enough video RAM to buffer an entire page or if they uncompress
it while the mirror is spinning. awesome, awesome. we keep
$complicatedlanguage around as an open-source emulator for those
who still need it. OS designers stood up for themselves and
invented their own font formats and font storage pools, which
they now hegemonically enforce font formats onto the font vendors
rather than the other way around. wysiwyg works, no more font
DRM, install fonts 1x, every page is printable, and at rated
speed, regardless of ``complexity'', no more hard drives inside
printers. hallelujah.
so my analagous argument is for (b), not to make the
kernel/userland boundary into a new virtual parallel port just
because it feels right to squeeze it into a straw. (though i
just contradicted reason (1).) At least just to make any
tinylanguages invented at interfaces extremelytiny and expressive
so the invention of the language makes less code in the overall
system even after implementing its interpreter, not to invent
boorish EE-inspired ``packing'' languages based on opcodes that
make lots of code for less data.
pgpLtemmtYk1Z.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
