Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Mar 1997 13:53:47 +1030 (CST)
From:      Michael Smith <msmith@atrad.adelaide.edu.au>
To:        terry@lambert.org (Terry Lambert)
Cc:        msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De
Subject:   Re: wd driver questions
Message-ID:  <199703180323.NAA14257@genesis.atrad.adelaide.edu.au>
In-Reply-To: <199703180225.TAA08818@phaeton.artisoft.com> from Terry Lambert at "Mar 17, 97 07:25:36 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying:
> > Ok, so I give you a pathalogical case.  I can think of several right
> > off the top of my head; most involve flash memory or read-only media
> > of some sort.
> > 
> > Of course, you have no way of knowing that the area of the disk that
> > you've elected to use is actually "scratch", do you?  Remember all
> > those nasty comments about MS operating systems eating peoples' disks?
> 
> The "cannonically correct" way to do this is to get the protected mode
> driver up in parallel with a VM86()-based INT-13 using driver, and if you
> can't tell two media apart, write on one of them with one driver and
> notice the change with the other.

Given that we have established that it's not feasible or desirable to 
write to the media, as it's not possible to determine where is a safe
place on said media to write to until after we have obtained the facts
that we are trying to obtain, this doesn't work.

Also, the practicalities involved in the int13 driver you're discussing
are horrific.

> > Given unlimited resources and patience, I'm sure you could do that.  With
> > the much scantier resources actually available to the bootloader, things
> > aren't so easy.
> 
> Linux does it.  Isn't FreeBSD as good as Linux?  Which particular
> resource do they have that FreeBSD doesn't?  I feel low trotting out
> the old "Linux" card, but you leave me little choice in this dialectic.

Linux does things somewhat differently.  I don't like their approach a
great deal, from what little I've studied it.  Perhaps their way works
for them; I'm seeking a way that works for me/us.  

I'm not shamed by your reference; I just can't see the relevance.

> Hopefully by "unlimited resources" you were referring to MS?

No, I'm referring to the dearth of _space_ in the second-stage bootstrap.

> If the bootloader was misled, DOS was identically mislead, and since
> all we really care about here is interoperability with DOS installed
> on the same drive (or another OS that must also care about interoperability
> with DOS installed on the same drive), it is *correct* to allow ourselves
> to be "misled".

What we care about is finding sectors on the disk, given some information
in c/h/s format.  It is only correct that we are similarly misled to DOS if
we were booted from the same source as DOS.  This is not necessarily so.

> The problems with the boot are MS OS boot interoperability problems,
> nothing more.  If you have an issue about dealing with interoperability
> problems by examining the software with which you are attempting to
> interoperate, well, all I can say is that you are unlikely to ever
> solve your problem.

I am not complaining about examining any particular OS.  I am
complaining about your suggestion that I should be subscribed to a
developer indoctrination service for an organisation and environment
that I find personally anathematical.  If said organisation or said
interoperability plaintiffs were to provide useful and relevant
documentation on the topic of interoperability, I would be happy to
study it.

> > Reading the partition data on the disk also requires that you are using
> > an MBR in the first place; another poor assumption.
> 
> No, it's not.  You should *always* have an MBR (or whatever passes for
> a native MBR on non-x86 computers -- on PPC's which comply with either
> PReP or CHRP, it's a DOS MBR.  On DEC Alpha's, it's a DOS MBR).  This
> is common sense, since it reduces the number of cases you must consider
> when you are trying to recognize the thing.

Supporting an MBR is good.  Mandating one is not the current Way Of Things.
It is valid to suggest that we should mandate the use of an MBR and 
corresponding partition information, but you will encounter users that
will Not Like This.

> > > o	Multiply the C/H/S geometry of the INT 13 ID's in question by
> > > 	the C/H/S limit values to get the absolute drive size.  Compare
> > > 	the size against the IDENTIFY size.  This will establish disk
> > > 	identity in the vast majority of cases.
> > 
> > Huh?  It is almost certain that, in the majority of cases, the C/H/S
> > size will _not_ match the drive's total reported size.  You would have
> > to apply a 'nearest fit' heuristic with some intelligence about
> > what is 'near'.  Not impossible, no, but not terribly simple.
> 
> Size-ordered BSD device list, bsearch for BIOS sizes.  *Very* simple.

Not so simple.  Introduce a set of devices that are found by the 
BIOS but not by BSD, and vice versa.  Sort amusingly.  Again, remeber
that we are only looking for one device to match the sizing of a 
single BIOS disk.

> Only write it if the values are wrong.  After you write it once, they
> aren't wrong.  In the "Virus alert" case (few machines offer this at
> the INT 13 level anyway), instruct the user to override.  We must
> already be instructing the user to do this to install our partition
> table entry anyway, right?  One partition table write can not be
> distinguished from another.  A write of that disk address range is a
> write of that disk address range.

A great many machines support int13 "virus alert" services.  It isn't
an issue at the point where we are writing a partition table as by then
we are in protected mode talking directly to the disk.

It's not a major issue, but it has the potential to be a support wart.

> > My current 'favorite' is the NetBSD libsa, which has all of the bits
> > that I need, modulo perhaps some more network drivers, however it doesn't
> > appear to have all of the "wonderful" ELF stuff that you keep raving
> > about.
> 
> I've never raved about ELF in NetBSD... not even in their boot code.

No, I am referring to the "segment colouring" and other things that you
appear (justifiably?) to feel are worthwhile using ELF for.  I am still
studying the libsa code, so I could well have missed a lot.

> Actually, you want to be able to load all segments with a certain set
> of tag bits from the kernel image file, which is a single ELF file.

MHO is that the kernel should _not_ be a monolithic file, but rather
the 'core' kernel and a collection of linkable objects (drivers,
optional extras, etc.)

This would allow constructing seperate kernels from a single repository
of objects, etc.

> The lack of a coherent kernel level vnode-as-descriptor based file
> I/O subsystem is one of the things that is wrong in the FreeBSD kernel.
> The vn_* routines are seriously incoherent compared to, for instance,
> the AIX kernel file I/O interface.

The solution to this is well known; I am hoping that you have provided
your changes to Julian and/or phk so that I can then pursue them with
regard to having them integrated.

> http://www.microsoft.com/win32dev/base/pefile.htm

Thanks for the reference.  Unfortunately, this document makes no
mention of "colouring" (in either spelling) boot or otherwise.  It
describes PE as a mutant form of COFF, which I already knew.

At best, I presume you are referring to the 'section characteristics'
attribute.

> Segment coloring refers to attribute bits for VM handling based on
> which ELF segment the page in question came from:
> 
> 	0x00000020	Code section
text
> 	0x00000040	Initialized data section
data
> 	0x00000080	Uninitialized data section
bss
> 	0x04000000	Section cannot be cached
I want to modify this and not care about the CPU
> 	0x08000000	Section is not pageable
I might have an interrupt handler in here
> 	0x10000000	Section is shared
I might use this for IPC
> 	0x20000000	Executable section
text
> 	0x40000000	Readable section
> 	0x80000000	Writable section
?!

The point, however, is that these attributes are not useful until the
VM system is up and running.  The initial linker pass has to run
_before_ this; still, it shouldn't be hard to walk the attributes at
a later stage to pass them on.

You could, at least, have renumbered the bits rather than use the
same (nonsensical) assignments that MS did 8)

> There is sample code available for download at the URL above.  If you
> need more, I've duplicated this effort to be able to load symbol
> tables from Microsoft Debug format and from SoftICE files into a
> non-statistical profiler for VXD's, when porting the Heidemann
> framework to Windows95, so I suppose I could give you some similar
> samples, though my header file for the reverse engineer was not
> nearly as complete as the ones on the URL above.

I couldn't care less about reading PE files.  My primary concern is
the communication of the attribute information to the VM system, and 
secondarily the parsing of ELF format files.

> The problem is in conversion from real-mode (INT-13/INT-21 based) disk
> drivers over to protected mode disk drivers.  I was simply giving an
> example of how it had been done.  Don't you have a technical library
> in your corner of the world?

The short answer is : No, we don't.  The longer answer is :
(technical) Books cost a small fortune in this country for some
inexplicable reason.  eg.  Stevens UNP, a fairly stock programmer's
staple, lists at AUD$90 (about US$70).  Ordering non-stock books can
often add 10-15% to that.

Public libraries tend not to have technical books.

> The main point is that the real mode code and the protected mode code
> for the VXD (PE format image) loader are the same, so there's precedent
> that it's possible to implement without a "smart" vs. "stupid" loader
> dichotomy.

TBH, I don't think this has any relevancy at all.  We are talking about 
environments that, rose-coloured glasses or no, are really quite different.

> 					Terry Lambert

-- 
]] Mike Smith, Software Engineer        msmith@gsoft.com.au             [[
]] Genesis Software                     genesis@gsoft.com.au            [[
]] High-speed data acquisition and      (GSM mobile)     0411-222-496   [[
]] realtime instrument control.         (ph)          +61-8-8267-3493   [[
]] Unix hardware collector.             "Where are your PEZ?" The Tick  [[



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703180323.NAA14257>