>
> I don't understand. Does the kernel code need to wait for the helper
> to finish while holding the semaphore? AFAICS, the helper is completely
> asynchronous, so it can simply do its job when the kernel has given
> up the semaphore.
It should be totally async witout any sem. there is no guar
Hi!
> +The userspace helper
> +
> +
> +The userspace splash helper (by default: /sbin/splash_helper) is called by
> the
> +kernel whenever an important event occurs and the kernel needs some kind of
> +job to be carried out. Important events include console switches and graphi
On Wed, Mar 09, 2005 at 04:40:09PM +0100, Arnd Bergmann wrote:
> Ok, I now saw that you call call_usermodehelper with wait==1. Why is that
> necessary? If you don't wait there, you don't need any hacks around the
> console semaphore, because the helper will simply wait for change_console
> to fini
On Middeweken 09 März 2005 17:54, Jon Smirl wrote:
> framebuffer already has a class registered. check out /sys/class/grpahics.
>
> You should be able to just call request_firmware and have it download
> your image whenever you need it. It doesn't have to be firmware,
> request_firmware will down
On Tue, 8 Mar 2005 23:37:29 +0100, Michal Januszewski <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 08, 2005 at 04:18:07AM +0100, Arnd Bergmann wrote:
>
> > It should probably just use its own hotplug agent instead of calling
> > the helper directly.
>
> I've just had a look at it, and it seems possib
On Middeweken 09 MÃrz 2005 03:05, Michal Januszewski wrote:
> On Wed, Mar 09, 2005 at 01:17:11AM +0100, Arnd Bergmann wrote:
> change_console()
> complete_change_console()
> switch_screen() == redraw_screen()
> con_switch() == fbcon_switch()
>
> From inside fbcon_switch(), we need to call the spla
On Wed, Mar 09, 2005 at 01:17:11AM +0100, Arnd Bergmann wrote:
> You also shouldn't create a class device every time you want to call
> kobject_hotplug. Note that every character device already has a class
> device associated with it, so you might be able to just use that to
> call kobject_hotplug
On Dinsdag 08 MÃrz 2005 23:37, Michal Januszewski wrote:
> On Tue, Mar 08, 2005 at 04:18:07AM +0100, Arnd Bergmann wrote:
>
> > It should probably just use its own hotplug agent instead of calling
> > the helper directly.
>
> I've just had a look at it, and it seems possible. From what I have see
On Tue, Mar 08, 2005 at 04:18:07AM +0100, Arnd Bergmann wrote:
> It should probably just use its own hotplug agent instead of calling
> the helper directly.
I've just had a look at it, and it seems possible. From what I have seen
in the firmware_class.c code, it would require:
- registering a cl
On Monday, March 7, 2005 9:00 pm, Matan Peled wrote:
> Arnd Bergmann wrote:
> > Nothing about the init command seems really necessary. Why not just do
> > that stuff from an /sbin/init script?
>
> I'm not a kernel hacker by any definition, but I'm pretty sure its
> neccasery because we want it to b
On Tue, 8 Mar 2005 04:18:07 +0100, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Dinsdag 08 März 2005 03:17, Michal Januszewski wrote:
>
> > +It's possible to set path to the splash helper by writing it to
> > +/proc/sys/kernel/fbsplash.
>
> It should probably just use its own hotplug agent inste
Arnd Bergmann wrote:
Nothing about the init command seems really necessary. Why not just do
that stuff from an /sbin/init script?
I'm not a kernel hacker by any definition, but I'm pretty sure its neccasery
because we want it to be done before /sbin/init is ran, AKA hide the kernel
messages :)
On Dinsdag 08 März 2005 03:17, Michal Januszewski wrote:
> +It's possible to set path to the splash helper by writing it to
> +/proc/sys/kernel/fbsplash.
It should probably just use its own hotplug agent instead of calling
the helper directly.
> +Splash protocol v1 specified an additional 'fbsp
Signed-off-by: Michael Januszewski <[EMAIL PROTECTED]>
---
diff -Nru a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX
--- a/Documentation/fb/00-INDEX 2005-03-07 16:50:34 +01:00
+++ b/Documentation/fb/00-INDEX 2005-03-07 16:50:34 +01:00
@@ -19,6 +19,8 @@
- info on the Matrox frame bu
14 matches
Mail list logo