[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
From:       "vivo75 () gmail ! com" <vivo75 () gmail ! com>
Date:       2012-07-31 23:57:08
Message-ID: 501870D4.2060802 () gmail ! com
[Download RAW message or body]

Il 31/07/2012 21:27, Michał Górny ha scritto:
> On Tue, 31 Jul 2012 15:16:34 -0400
> Rich Freeman<rich0@gentoo.org>  wrote:
>
>> On Tue, Jul 31, 2012 at 10:56 AM, Ian Stakenvicius<axs@gentoo.org>
>> wrote:
>>> Although that is true, it would be -WAY- too slow to generate said
>>> list via equery/q* helpers; I think that's where the
>>> extended-attributes and/or cache idea comes into play.
>> I agree.  This needs to be high-performance when it comes to
>> individual file access.  If it takes 10 seconds per build to populate
>> some database or set up a bazillion bind mounts that isn't the end of
>> the world, but if it takes an extra 0.1 seconds every time a file is
>> read that could add up VERY fast on a large build.
> I'd be more afraid about resources, and whether the kernel will be
> actually able to handle bazillion bind mounts. And if, whether it won't
> actually cause more overhead than copying the whole system to some kind
> of tmpfs.
If testing show that bind mounts are too heavy we could resort to 
LD_PRELOAD a library that filter the acces to the disk,
or to rework sandbox to also hide w/o errors some files,
with an appropriate database (sys-apps/mlocate come to mind) every 
access will have negligible additional cost compared to that of 
rotational disks.
>> Ideally I'd like to see the same thing extended to run-time, and short
>> of writing some entirely new security model into the kernel or taking
>> namespaces to a whole new level, part of me thinks that
>> auto-generating SELinux policies might be the solution, so that the
>> existing mechanism can be extended.
>>
>> The mad scientist in me keeps thinking up crazy schemes so that
>> package collisions can be handled by each package just seeing whatever
>> it wants to see - maybe the entire filesystem looks different
>> depending on what app you use.  Then I realize that bash is an
>> application, and how on earth would a human make sense of a system
>> where no file has any stable identifier other than maybe a
>> content-hashed key.  Then that makes me wonder why we link to
>> libraries by filename anyway, when we could just give each library a
>> GUID and version, and maybe a more general identifier for cases where
>> you have alternate implementations.
>>
>> But, as long as we're still just running Gentoo on Unix-like OSes
>> maybe tweaking the jail is a good place to start...
>>
>> Rich
>>
>
>


[prev in list] [next in list] [prev in thread] [next in thread]