[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

pc386 on 386sx





On Thu, 29 Jul 1999, erik.ivanenko wrote:

> joel at oarcorp.com wrote:

> 
> I don't follow the notion of "on top of".  I thought I got
> "beside/below", but then got very confused. What makes a piece of
> code/module "on top of" another?  There is some sort of dependency,
> but it is not clear to me.  Is it a "used by" relationship? eg.

In my mind, yes.

> Suppose routine X is present in libcpu.  Routine X is generic to the
> i386 family, has no dependence on the RTEMS executive -- it does not
> use RTEMS routines.  Routine X is "used by" the BSP and also "used by"
> the executive.  Is routine X "ontop"/"beside"/"below" RTEMS?  I'd
> think "below" both the BSP and RTEMS.

Yes in this case it would be purely below both the BSP and RTEMS.

And from a build standpoint could thus safely be built before RTEMS.

> But routine X manipulates vector tables, an operation that you have
> claimed is "above" RTEMS.

This is an example of where it gets sticky.  If this routine is truly
independent of the BSP and RTEMS, then it is "below".

However, if it is using internal RTEMS structures to get to the vector
table, then I would call it "beside" to mean that it is neither strictly
below RTEMS or strictly above it.  It is logically at the same level and
is co-dependent.

libcpu has turned into the conglomeration of a few things:

  + some is strictly speaking independent of RTEMS. "below"
  + some is device drivers 			    "strictly above"
  + some is support code for RTEMS.                 "beside"

> I am missing something!

Not really.  This whole issue of what is in libcpu and what is its
relationship to the code in score/cpu and the bsps is complex.  If you
drew some type of layered picture of the system, some would end up very
high in the picture (device drivers) and some would end up near the bottom
(cpuModel.S, GDT routines, etc).  

All of the code in there is reusable code that is dependent on the CPU
model.  However some of it is also dependent on RTEMS (device drivers) and
some of it is not and can be used in the RTEMS port itself (cpuModel, GDT
routines, etc).  

This conflict is what makes the placement of libcpu hard to discuss.  I
see EriC's point that some of libcpu is useable by both RTEMS and the
application while some should only be used by the application.  BUT all of
it is useable by applications.  The routines in score/cpu are used inside
the executive and strictly speaking should be off limits to application
code.

> Also, some routines like irq_init are in libbsp/i386/shared.  These
> could just as easily be in libcpu could they not? 

This is a bit different since it assumes more than the basic i386
interrupt structure.  It assumes that the i8259 PIC is used in the same
manner as on a PC.  This crosses the line of being purely CPU dependent.

> Other routines like printCpuInfo in libcpu/displayCpu.c should be in
> libbsp/i386/shared, since printk is available only in libbsp.
> Does this mean printCpuInfo is "above" libbsp?

Strictly speaking this is true.  

Although I would like to argue that we should have a printk in every BSP. :)

This would put printk into the (currently non-existent) BSP API. Again :)

--joel
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985