[lug] booting and kernel compiling (was dumpdates)

John Starkey jstarkey at ajstarkey.com
Wed Aug 16 18:51:04 MDT 2000


Wayde. 

I see this now. Thanks. I think the important thing now is to just see it
in action. It's one thing to hear and understand the theory, but to then
be able to notice things that depend on this theory when they happen. It's
just a matter of time now. BUT I wouldn't be able to notice it if you and
Chris hadn't spents so much time explaining how it works.

Thanks,

John

On Wed, 16 Aug 2000, Wayde Allen wrote:

> On Tue, 15 Aug 2000, John Starkey wrote:
> 
> > > The kernel is really just a
> > > standardized interface to the system hardware.  
> > 
> > Ok, to be philosophical. What you're saying is that the kernel really
> > doesn't have anything to do with keeping the insides going, actively. I
> > guess that makes sense. Cron though, it get's executed something
> > what would that be? I assume it's fed from the internal clock (not the
> > bios right, bios is only the initial boot mechanism)?
> 
> I'm not sure I follow.  The kernel is your interface to the hardware.  If
> as you say it has nothing to do with keeping the insides going I wouldn't
> need to buy a computer.
> 
> Cron is a computer program.  It isn't a part of the kernel.  Yes, it uses
> the system clock.  You are correct that the bios is just the initial boot
> mechanism.  Once Linux starts the bios is no longer relevant.
> 
> > > It doesn't have a reason
> > > or desire to call the mv command.  That is where you come into the
> > > picture.  You were the one who tried to invoke that command.  The path is
> > > part of the shell environment that you interact with.
> > 
> > The mv command doesn't even use the kernel then. Pass any arguments??
> 
> Huh ... ?  Of course the move command uses the kernel.  Any program
> running on the system uses the kernel since the kernel is what talks to
> the hardware.  If it didn't use the kernel it wouldn't be running on the
> system hardware and you wouldn't need a computer!
> 
> The kernel basically provides a standard software interface to the
> hardware.  For instance, in Unix everything is treated as a file.  If you
> go to /dev for instance you will find your disks listed as /dev/hd? or
> /dev/sd?.  To read and right to them you really just need to read and
> write these files, the kernel handles all of the issues of finding and
> retrieving the appropriate pieces of data on the drives.  The same thing
> goes for reading the keyboard or writing to the screen etc..  The
> advantage of this kind of abstraction is that if you change the underlying
> hardware you only need to re-write the kernel to support the hardware
> rather than every program on the system.
> 
> - Wayde
>   (wallen at boulder.nist.gov)
> 
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 





More information about the LUG mailing list