headers
François Revol | 1 Aug 2002 01:17
Picon
Favicon
Gravatar

Re: Add-ons/Module problems/ideas??

En réponse à Rudy Gingles <rudyatek@...>:

> So, basically modules and drivers ARE the same thing? Just two ways
> of interfacing with them due to Unix tradition? This still doesn't
> entirely make sense, partly because I didn't know BeOS was that
> influenced by tradition, and partly because it still seems redundant
> to me. Is this something that will change in R2? I'm still trying to
> find a reason why modules and drivers must exist as separate
> entities, with the kernel treating the two differently.
> 

No.

In BeOS, only drivers are able to publish device files (/dev entries),
modules aren't, they are meant to be called by kernel drivers.
( IIRC NewOS doesn't do the distinction between the too...)

You can view this as a tree (not exactly, but), with modules at intersections,
and drivers at the leaves.
Modules can call other modules, drivers are only loaded by the kernel.

François.
Permalink | Reply | 20 comments |
headers
Isaac Yonemoto | 1 Aug 2002 02:08
Favicon

Re: Add-ons/Module problems/ideas??


Is it possible to have a kernel that can reboot itself?  I think I posted
this on the suggestions list, but I didn't get much of a response.

1.  The kernel suspends each thread, recording the priority of each thread
as they are taken down.

2.  The kernel takes the entire memory space and transfers it to a
known position on disk.

3.  The kernel records (whatever other critical information it needs).

4.  The kernel shuts down.  (either shutting down the machine, also, or
rebooting the kernel).

On bootup (if say, spacebar is pressed), then it boots up normally,
clearing out all of the previously recorded information.

Otherwise, after the FS is loaded, it transfers the entire memory space
back up to the machine from disk, and whatever other information was
transferred.  Then it one-by-one turns on each thread.

I guess there are a few important things that need to be addressed (what
to do with semaphores floating about, thread_ids, port_ids, area_ids
needing to be conserved, et cetera)...

Are there real problems with this idea?  Because, it seems to me, that
implementing something like this would allow us to do reboot-less kernel
upgrades, and neato instant-on features.  Perhaps this belongs in
glasselevator, but I don't see why something like this wouldn't be "R5
(Continue reading)

Permalink | Reply | 19 comments |
headers
Timothy Covell | 1 Aug 2002 02:28

Re: Add-ons/Module problems/ideas??

On Wed July 31 2002 20:08, Isaac Yonemoto wrote:
> Is it possible to have a kernel that can reboot itself?  I think I posted
> this on the suggestions list, but I didn't get much of a response.
>
> 1.  The kernel suspends each thread, recording the priority of each thread
> as they are taken down.
>
> 2.  The kernel takes the entire memory space and transfers it to a
> known position on disk.
>
> 3.  The kernel records (whatever other critical information it needs).
>
> 4.  The kernel shuts down.  (either shutting down the machine, also, or
> rebooting the kernel).
>
> On bootup (if say, spacebar is pressed), then it boots up normally,
> clearing out all of the previously recorded information.
>
> Otherwise, after the FS is loaded, it transfers the entire memory space
> back up to the machine from disk, and whatever other information was
> transferred.  Then it one-by-one turns on each thread.
>
> I guess there are a few important things that need to be addressed (what
> to do with semaphores floating about, thread_ids, port_ids, area_ids
> needing to be conserved, et cetera)...
>
> Are there real problems with this idea?  Because, it seems to me, that
> implementing something like this would allow us to do reboot-less kernel
> upgrades, and neato instant-on features.  Perhaps this belongs in
> glasselevator, but I don't see why something like this wouldn't be "R5
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fred K Ollinger | 1 Aug 2002 03:02
Favicon

Re: Add-ons/Module problems/ideas??

> Extending the kernel is a more recent idea. Allowing the kernel to
> invoke other kernel level code at run time makes the kernel more
> modular and easily enhanced by the work of others. It also reduces the
> size of the kernel by not requiring everything to be statically linked
> in with the kernel itself.

All true, here. I am going to add that modules don't have to be device
drivers. There are linux kernel drivers which are for filesystems. Others
give firewalling functionality. So many parts of the kernel space in linux
kernel can be modularized including device drivers. In fact _Linux Device
Drivers_ tells about how to make a loadable module that just registers
itself and says hello. A hello world module!

> There is no requirement that drivers be dynamically loaded. Until
> recently, most drivers were build into the kernel. However, the trend
> now is definitely to let the drivers be loaded on demand at run time.
> These kind of drivers, therefore, have to be written as some kind of
> kernel extension.

All true, in fact using initrd, even things such as the filesystem module
for / can be a module. This way, you can change filesystems (to xfs) and
not have to recompile the kernel, making a xfs static. This assumes you
have compiled xfs as a module against your current kernel sources. This
doesn't have to be done during your first compile.

> Ok, that's my take. Anyone care to add to this or disagree?

I agree w/ all of it.

While I believe the 7 MB kernel issue, I don't think it's that big of a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Phipps | 1 Aug 2002 03:43
Picon

Re: Add-ons/Module problems/ideas??

Issac - 

I have given this a lot of thought and I think that I would like to do something
like this for R2. But that is a GE thing. ;-)

>
>Is it possible to have a kernel that can reboot itself?  I think I posted
>this on the suggestions list, but I didn't get much of a response.
>
>1.  The kernel suspends each thread, recording the priority of each thread
>as they are taken down.
>
>2.  The kernel takes the entire memory space and transfers it to a
>known position on disk.
>
>3.  The kernel records (whatever other critical information it needs).
>
>4.  The kernel shuts down.  (either shutting down the machine, also, or
>rebooting the kernel).
>
>On bootup (if say, spacebar is pressed), then it boots up normally,
>clearing out all of the previously recorded information.
>
>Otherwise, after the FS is loaded, it transfers the entire memory space
>back up to the machine from disk, and whatever other information was
>transferred.  Then it one-by-one turns on each thread.
>
>I guess there are a few important things that need to be addressed (what
>to do with semaphores floating about, thread_ids, port_ids, area_ids
>needing to be conserved, et cetera)...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Phipps | 1 Aug 2002 03:46
Picon

Re: Add-ons/Module problems/ideas??

>François wrote:
>> However I've been wondering about issues like rescanning, but I still want to
>> see how usb mosules deals with this before complaining =)
>
>The way "usbd" module ask devfs to reload the driver who register him 
>wanting being notified when some specified USB device(s) appear or disapper 
>on USB bus is unknown, that's right.
>In fact, the USBD way of doing was said to be a prototype of a new, more 
>dynamic, driver API by Be Inc. engineer in some BNewsletter (can't find 
>it now, sorry). We'll have to look at this issue, but Michael Phibbs 
>don't plan binary compatibility with USB drivers, or did I miss something 
>here?

First off, there are no 'b's in my name. ;-)
Secondly, the only comment I made (that I remember) about USB compatability is
that I don't care if the USB bus manager from R5 runs under our kernel or not.
Apparently, there were some issues - some of the bus managers do bad, evil things
with undocumented or weird kernel functions. So I decided from the outset that
we would have to rewrite those. There are only a few - PCI, SCSI, IDE, USB, PCMCIA.
Permalink | Reply | 1 comment |
headers
Manuel Jesus Petit de Gabriel | 1 Aug 2002 05:25

Re: Add-ons/Module problems/ideas??


----- Original Message -----
From: "Philippe Houdoin" <philippe.houdoin@...>
To: <openbeos@...>
Sent: Wednesday, July 31, 2002 8:24 AM
Subject: [openbeos] Re: Add-ons/Module problems/ideas??

> François wrote:
> > However I've been wondering about issues like rescanning, but I still
want to
> > see how usb mosules deals with this before complaining =)
>
> The way "usbd" module ask devfs to reload the driver who register him
> wanting being notified when some specified USB device(s) appear or
disapper
> on USB bus is unknown, that's right.

#include <unistd.h>
#include <fcntl.h>
#include <string.h>

int
main(int argc, char **argv)
{
    for(int i= 1; i< argc; i++) {
        int h= open("/dev", O_RDWR, 000);
        write(h, argv[i], strlen(argv[i]));
        close(h);
    }
(Continue reading)

Permalink | Reply | 2 comments |
headers
Massimiliano Origgi | 1 Aug 2002 12:53
Favicon

Re: Add-ons/Module problems/ideas??

>Apparently, there were some issues - some of the bus managers do bad, evil 
>things
>with undocumented or weird kernel functions. So I decided from the outset 
>that
>we would have to rewrite those. There are only a few - PCI, SCSI, IDE, USB, 
>PCMCIA.

Yes, better rewrite these things now and clean the API, it saves time and 
bugs.
Btw, don't forget firewire, it's really important for us (and AFAIR *BSD has 
a complete implementation now).
--

-- 

Massimiliano Origgi
    http://www.intuiware.com    mailto:max@...
        Squeezer 2.1 available!
            WorkspaceSwitcher 2.1 available!
Permalink | Reply | 0 comments |
headers
Michael Noisternig | 1 Aug 2002 13:11
Picon
Picon

Re: Add-ons/Module problems/ideas??

Isaac Yonemoto wrote:
[snip]
> Are there real problems with this idea?  Because, it seems to me, that
> implementing something like this would allow us to do reboot-less kernel
> upgrades, and neato instant-on features.

In short, this idea is plain stupid.

Longer answer: If you want to upgrade the kernel while keeping all your 
programs at the current state then you not only have to record all the 
kernel data (besides the user memory) but because a different kernel for 
sure has different data structures you have to find a way to convert 
your old ones to the new ones which is basically impossible.
Permalink | Reply | 1 comment |
headers
François Revol | 1 Aug 2002 13:08
Picon
Favicon
Gravatar

Re: Add-ons/Module problems/ideas??

Thx, but that I know already :)))))
I rewrote the rescan command that did just this :^)
My concern was if kernel modules could do this safely,
*without deadlocking* devfs,
*without stack overflow* if we deal with recursing calls.

François.

En réponse à Manuel Jesus Petit de Gabriel <freston@...>:

> 
> ----- Original Message -----
> From: "Philippe Houdoin" <philippe.houdoin@...>
> To: <openbeos@...>
> Sent: Wednesday, July 31, 2002 8:24 AM
> Subject: [openbeos] Re: Add-ons/Module problems/ideas??
> 
> 
> > François wrote:
> > > However I've been wondering about issues like rescanning, but I
> still
> want to
> > > see how usb mosules deals with this before complaining =)
> >
> > The way "usbd" module ask devfs to reload the driver who register
> him
> > wanting being notified when some specified USB device(s) appear or
> disapper
> > on USB bus is unknown, that's right.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane