On (08/26/07 12:10), Artem Kachitchkine wrote:
>
>>> requested properties into the kernel - it has some boot-related issues,
>>> scales poorly and is, by and large, an architectural wart. It would be
>> could you be specific? I'm not sure I understand the boot-related issues,
>
> Possible scenarios were mentioned in Samant's presentation and in the
>v Brussels design document.
These scenarios have been discussed earlier, in email with Jerry
Gilliam. As such, it is no worse than any other door upcall made
from kernel to user. As I recall, the discussion during
Samant's presentation brought up a number of scenarios, and both
Brussels and Clearview projects addressed each scenario correctly (though,
admittedly, fixing 6545020 would provide a more elegant solution)-
could you be more specific?
>> and the scalability concerns.
>
> Can dladmd handle multiple upcalls simultaneously?
Yes.
BTW, one important point to emphasize here is that "dladmd" is
only a daemon that is being used in the prototype temporarily,
until a merge with Clearview occurs. Eventually dladmd == dlmgmtd
(Clearview daemon) which has many more requirements than dladmd,
including the need to handle multiple upcalls.
>> How would the latter be resolved via
>> 6545020? How are these issues avoided for other kernel->user door
>> upcalls elsewhere in the kernel?
>
> If we forget for a moment about SMF, for simplicity, and imagine that we
> remove dladmd and instead load /etc/dladm/linkprop.conf directly from the
> kernel. If the file is in the boot archive, properties are available at any
> point in boot. Unlimited number of kernel threads can access it
> simultaneously.
there is a general problem of getting access to configuration from
the kernel: parsing files like linkprop.conf from the kernel is not the
most elegant solution either- here are some reasons why:
for the particular case of linkprop.conf, there are other problems.
For a start, the syntax in linkprop.conf is Project Private, and it's
dangerous to make assumptions about its format (as an example, currently
the Clearview proposal is moving this to xml. Tomorrow another project
can decide to move it to some other location/format..).
There are other problems. For example, Brussels
is using libdladm to map property name to encoded property number
for the Public properties, and doing as much string processing in
user-space as possible. For example, if there is a public property
foo which takes an int array input, i.e. foo=<val1>,<val2>,..,<valn>
the library does all the string processing and send down an array
of ints to the kernel. Let's say we have the kernel parsing
linkprop.conf on each mac_register(). Even if I find some way to share
the prop_name <-> prop_number mapping for public properties via system
header files, we may still have some sticky issues around setting the
property values. We have to either introduce constraints on public
properties (e.g., they cannot take array input, no enums allowed etc.),
or we have to duplicate some of the string processing code for public
props between libdladm and the kernel. Neither solution is particularly
attractive.
As for scalability: what happens when dladm is writing to the file,
while some driver is trying to attach, and get the latest configuration
from that file? the kernel and user-space still have to perform
some sort of synchronization mechanism here.
Having said all this, I acknowledge that there is a basic
problem that although the SMF repository is nicely accessible from
user space, multiple projects (Clearview, Brussels, probably Crossbow)
have a need to be able to access this data in some stable
way from the kernel. And there are other subsystems (as evidenced
by the number of file processing functions in modsysfile.c)
that have a similar need.
And although the door-upcall is not the most elegant way to do it,
I don't see it is a significant architectural flaw ("wart"), as
your email suggests. If it were, the entire door upcall mechanism
usage in the kernel should be re-examined, since door upcalls are
used all over the place. And I would like to emphasize that this
particular part (door upcall) is really encapsulated in
"mac_restore_prop()" so that when a more elegant solution is available,
the internals of mac_restore_prop could be modified without any
driver-rewrite, so that we have not jeopardized any part of the
Brussels architecture by making this choice.
--Sowmini
