Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8403

Re: System log and format of log entries

Show all headers | View raw

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x1uhssosyfako5@localhost...
> On Wed, 15 Jul 2015 12:34:22 -0400, Benjamin David Lunt <zfysz@fysnet.net> 
> wrote:
>
>> The case here is that on boot up, while still in (un)real mode
>> and using the BIOS, my loader thinks that it is booting from a
>> standard FDC floppy drive using INT 13h services.
>
> Is it safe to use the BIOS from unreal mode?

Sure.  The segment registers are still set to values used
by real mode, their limits are just extended.  As long as you
don't use the high 16-bits of a register, when calling BIOS
services, the BIOS knows no difference.

As mentioned earlier, I use a 4meg+ stack located above the
1Meg mark for my loader, which requires unreal mode.  However,
when I need to call a BIOS service, I have to call the wrapper
which will setup a stack within the real mode address space,
use this stack, then copy its contents back to the unreal mode
stack before returning to the caller.

>> Did that answer your question?
>
> No, not really ...
>
> That explains how you solved your issue, and why you kept
> asking us about methods of identifying the boot drive over
> the past few years.
>
> Instead of tracking down the boot device by serial number,
> I think you could possibly do one of two things to *not* need
> to locate and use actual "missing" boot drive:
>
> 1) load the boot image into RAM and use RAM as the boot drive

This is a good idea as long as the boot drive is a floppy or
a fairly small different form of media device.  However, what
if I am booting from an external USB hard drive that is a 160gig
drive?

> 2) don't disable USB floppy emulation for the USB device

If I don't disable the USB floppy emulation, then that particular
USB device is unusable by my OS.

However, once you move from (un)real mode to pmode, the BIOS
is no longer available with disables the USB floppy emulation
anyway.

Also, when enumerating the USB devices, how do you know which
USB device is being "emulated" by the BIOS?  What if I have
an external USB Floppy drive and two thumb drives already
attached?  How do I know which one of these three devices
was booted from and which one the BIOS was emulating as a
FDC or HDC image?

The problem I am running in to, which happens occasionally, is
that once my kernel has loaded, it needs to know which device it
booted from to continue to load drivers from that device.
If more than one bootable image is installed, one of these
bootable images could have different versions or even completely
different Operating Systems all together.

Let's say that I have been working on the USB code to read
a USB thumb drive, and lets say that I call this version
of the USB module version 1.23.45.  Now let's say that I
insert an external USB floppy drive and start working on
the USB module code to use it. Then, I have worked on this code
and got the code to work use an external USB floppy drive
and now have the code to version 5.43.21.

So, let's boot the system from the USB floppy drive.  Once
my kernel has been loaded, what if it found the USB thumb
drive first, found that it is a valid FYSOS image and continued
to load the drivers.  Since the USB module code on the thumb
drive is version 1.23.45, it now cannot find the USB floppy
drive due to the fact that it is an old driver.

Please put aside the fact that all I have to do is update
the thumb drive with the new driver.  I am trying to make
a point here that I need to know which device I booted from
to retrieve the correct and most recent OS files.

For example, let's say that I am building version
1.33.33 and happen to have version 1.22.22 on a
different partition or a complete different device attached
to the system.  What if the kernel happens to find that
1.22.22 version and loads drivers from that device instead
of the booted from 1.33.33 version device.

I know it is a rare case and something that I shouldn't
worry too much about, but why not?  :-)

Ben

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.fysnet.net/index.htm
http://www.fysnet.net/osdesign_book_series.htm
To reply by email, please remove the zzzzzz's

Batteries not included, some Assembly required. 

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

System log and format of log entries "James Harris" <james.harris.1@gmail.com> - 2015-07-14 11:42 +0100
  Re: System log and format of log entries "James Harris" <james.harris.1@gmail.com> - 2015-07-14 11:59 +0100
  Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 03:23 -0400
    Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 22:46 -0400
  Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 03:33 -0400
    Re: System log and format of log entries Peter Cheung <mcheung63@gmail.com> - 2015-07-15 00:47 -0700
    Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 22:42 -0400
      Re: System log and format of log entries "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-16 12:18 -0700
        Re: System log and format of log entries "Mike Gonta" <mikegonta@gmail.com> - 2015-07-16 15:50 -0400
          Re: System log and format of log entries "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-16 13:24 -0700
            Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-17 06:39 -0400
              Re: System log and format of log entries "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-17 10:27 -0700
                Re: System log and format of log entries "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-21 16:38 -0700
  Re: System log and format of log entries "James Harris" <james.harris.1@gmail.com> - 2015-07-15 15:15 +0100

csiph-web