Re: UML-stuff

From: Amon Ott <ao@rsbac.org>
Subject: Re: UML-stuff
Date: Fri, 16 Feb 2001 10:30:09 +0100

Next Article (by Date): Re: UML-stuff Jörgen Sigvardsson
Previous Article (by Date): UML-stuff Jörgen Sigvardsson
Top of Thread: UML-stuff Jörgen Sigvardsson
Next in Thread: Re: UML-stuff Jörgen Sigvardsson
Articles sorted by: [Date] [Author] [Subject]

On Don, 15 Feb 2001 Jörgen Sigvardsson wrote:
> I think I have now established uml (0.38) and rsbac (1.1.0) can coexist in a 
> nice manner. I have now booted rsbac+uml with procfs, devfs, non-maint.kernel 

Good! I am just setting up an UML test root partition with SuSE 7.0 for
testing. UML is really cool!

> using MAC, ACL and REG without any major hiccups (it still complains a little 
> about /proc and /dev - rsbac_get_attr() can't lookup device)(using slackware 
> dist). 

This is only a harmless timing problem during init.

> BTW, are there any "test suites" out there? 

A kernel compile seems to be fine. Also, I tend to tar cvf /dev/null /
Some networking would also be fine, e.g. with nfs - useful for installation
anyway.

> Amon, since I am going to actively use uml for my own work (until it is 
> finished), I would be happy to maintain the patches, unless you have 
> something else in mind.

This is fine with me. Thanks!

> I have basically two options for maintaining the patches:
> 1) a patch which is applied against an already patched UML-kernel
> 2) a patch which is applied against an already patched RSBAC-kernel
> 
> Do you have any preferences regarding this? I did it by using the 2) option, 
> but I guess 1) is equally as nice. I guess it's just a matter of semantics. 
> What sounds better: 
> * An RSBAC-enabled UML-kernel
>  - or -
> * A UML-enabled RSBAC-kernel

OK: What I'd like to include into the main RSBAC dist is a patch that is
additional to the other ones. So RSBAC with UML looks like:

1. untar rsbac in kernel dir
2. apply std. RSBAC patch
3. apply std. UML patch
4. apply RSBAC-for-UML-patch (your part)
5. configure and compile

1., 2. and 3. should be as independent as possible, so e.g. 3. could be done
before 2. or 1.
2. already depends on 1. for patches coming after a release.

Can uml and rsbac patches coexist? If not, we should provide an RSBAC patch
against an uml patched kernel.

If possible, 4. should only modify anything in arch/um and include/asm-um. All
changes to std. rsbac code must be ifdef'd, otherwise maintaining and
development get a terrible mess.

Important: The patches should be real patches, all new files must be in the
main tar archive.

This setup also makes your work more independent from mine.

Amon.
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.