>
> 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
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
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
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 graphic
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
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
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
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
On Middeweken 09 Mrz 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 splash
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 possible. From
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 download
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 finish.
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
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
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
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
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 be done
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
On Dinsdag 08 Mrz 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 seen
in
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
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
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
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
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
On Dinsdag 08 Mrz 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
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 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 instead of
28 matches
Mail list logo
