Hello Wolf,
let me just amend Jiri's reply.
At first I planned to add a a /ctl node to comp:0/ directory, but then
decided that it will be rather natural to control compositor through
it main node. But if you want the former way, I'll do.
It's really just a matter of taste, not functionality. But having two
nodes with very similar names is probably not very elegant.
Well, then what to do with compositor which starts before driver?
Aside from the explanation that Jiri already gave you, the compositor
should be able to accept hot-plugged drivers and ideally also
hot-unplugged drivers.
The compositor really shouldn't rely on the fact that the driver(s)
finish their initialization soon enough before the compositor starts.
* CamelCase in libvbe
It was done on purpose: to name structures like in VBE standard. Could
naming convention be weaken here?
If you name the structure vbe_info_block_t, it will be still easily
recognizable to somebody reading the standard, but it will also comply
to our naming convention.
I mean, the VBE standard is ancient and generally well known. It is not
a bleeding edge and yet unimplemented technology, thus I see very little
reason to pedantically stick to the verbatim names from the specs.
Thank you. I guess its time to develop mechanism to anknowledge kernel
console about new mode parameters. At first I thought to implement a
new syscall
I would adapt the current SYS_DEBUG_ACTIVATE_CONSOLE syscall. It is
currently used for programatically activating the kernel debugging console.
It could be renamed to SYS_DEBUG_CONSOLE and extended to be used not
only for activating the console, but also for informing the kernel about
the new mode parameters.
but after a quick look at kernel sources I discovered
such thing as sysipc ops. I plan to add a new specific operation. But
may be I've missed something?
I really don't think this would we wise. The sysipc_ops are related to
IPC calls, but the user space does not communicate with the kernel via
IPC. It uses plain syscalls.
If you are speaking about spaces before function prototypes, they are
aimed to reflect hierarchy of parameters parser. Sort of pretty
printing.
If you want that I suggest you use a common prefix for the symbol names.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel