FreeLists / openbeos / [openbeos] Re: kernel mime_table module

[Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>]

On 2005-01-08 at 21:55:07 [-0500], Axel Dörfler wrote:
> Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx> wrote:
> > I don't really like the idea of putting the mime types in the kernel. 
> > Mostly 
> > for the reasons that Ingo says. But also because I think that the kernel 
> > should 
> > do only what only the kernel can do. In other words, without trying to be 
> > extreme, I think that the smaller and tighter the kernel is, the better. 
> 
> The kernel *could* do anything, it's more of a question if it should do.
> And the whole thread was basically to move this away from dosfs (where it 
> currently is) to some userland API.

What I am saying is that the kernel should do as little as is realistically 
possible. The smaller and the simpler, the better. :-)
 
> > That isn't to say a micro-kernel or anything, but a monolithic kernel that 
> > provides only the most necessary of services. 
> > 
> > With hyper threading (an idea that I think will die) and multi-cores (an 
> > idea 
> > that I think will thrive) not to mention multi-processor machines becoming 
> > more 
> > prevelent (esp on the PPC side), it seems to me that there may well be a 
> > lot 
> > more circumstances where you will have both the user land side (Registrar 
> > in 
> > this case) and kernel land active at the same time. That would be a very 
> > ideal 
> > situation for this particular situation.
> 
> I am not sure if I understand you correctly, but the kernel/userland stuff 
> has just nothing to do with this. The kernel has many threads running and if 
> you got SMP, they may all run simultaneously.

What I was thinking about is some way in which a user land process could 
receive the benefit of kernel services without the overhead of a task switch 
because some other processor is idle and the kernel thread can run on it.