FreeLists / openbeosstorage / [openbeosstorage] Re: platform_kernel_args &libdisk_device_manager.so

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2003-10-25 at 02:45:38 [+0200], you wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On 2003-10-24 at 11:39:23 [+0200], you wrote:
> > > Compiling libdisk_device_manager.so was failing due to
> > > ddm_userland_interface.cpp needing the boot platform specific
> > > platform_kernel_args.h file in the search path, so I added:
> > > 
> > > UsePrivateHeaders [ FDirName kernel boot platform
> > > $(OBOS_BOOT_PLATFORM) ] ;
> > > 
> > > to the Jamfile for libdisk_device_manager.so. It doesn't appear to
> > > muck
> > > anything up, but I'm not sure if this how you all want this handled
> > > or not
> > > so I thought I'd mention it. :-)
> > Mmh, that must be something Axel introduced (accidentially?), as it
> > seems to
> > be boot loader specific. We indirectly include <vm.h>, and I guess
> > the
> > source is to be found somewhere in this direction.
> 
> Actually, it's not accidently. It's the same mechanism as in "arch", I
> probably just have messed up its implementation.
> The actual platform + arch define the build target, and we need headers
> from both sources in the kernel (i.e. for the kernel_args structure
> that is passed from the boot loader to the kernel - it has an arch and
> a platform specific part).

Maybe I just misunderstand you, but shouldn't a header that is used by both 
boot loader and kernel use #ifdefs when including headers that differ for 
boot loader and kernel, so that for the ddm we wouldn't need to add a boot 
loader specific include dir, since no boot loader header would be included 
when compiling it?

> We just don't have a private/kernel/platform directory, because we
> might not need one - most platform dependent things are resolved
> earlier (but kernel serial debug output would probably be platform
> specific).
> 
> Since the Pegasos is very PC-like in some details, we'll have to
> complicate our build structure anyway. Maybe we could introduce a new
> platform legacy_pc to catch both :-)

Feel free to add it. :-P

CU, Ingo