Hi,
On Sun, Apr 26, 2009 at 10:01:56PM +0100, Da Zheng wrote:
> I logged all RPCs and tried to analyze them. (antrik, I was wrong.
> There aren't 100, 000 RPCs. The number of RPCs to the Mach during the
> subhurd booting is about 20,000 - 60,000). I found something
> abnormal, but I am not sure
Hello,
writes:
> On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
>> OTOH, implementing unionmount as extensions to translator libraries
>> would mean faster operation and automatic inclusion of the
>> functionality in *every* existing translators, but modifying something
>> would r
Hi,
On Thu, Apr 09, 2009 at 07:29:27PM +0200, Carl Fredrik Hammar wrote:
> On Tue, Apr 07, 2009 at 12:20:40AM +0300, Sergiu Ivanov wrote:
> > This would yield faster code (no extra context switch, the shadow
> > node is within the main translator) and more control over the
> > merging functionali
Hi,
On Thu, Apr 09, 2009 at 10:03:27PM +0300, Sergiu Ivanov wrote:
> writes:
> > On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:
> >> This approach will require adding some user-modifiable flag to the
> >> corresponding translator library that will allow to switch on and
> >> off
Hi,
On Fri, Apr 10, 2009 at 08:51:03PM +0300, Sergiu Ivanov wrote:
> writes:
> > On Wed, Apr 08, 2009 at 08:17:30PM +0300, Sergiu Ivanov wrote:
> >> You see, I suppose that some time later we will be adding some
> >> specific merging rules, which would be very difficult (if not
> >> impossible)
Hi,
On Thu, Apr 09, 2009 at 08:08:58PM +0200, Carl Fredrik Hammar wrote:
> > > unionmount is expected to merge the filesystem on which it sits
> > > with the filesystem exposed by the translator it is asked to start
> > > in unionmount mode (further referred to as ``the Translator'').
> >
> > Na
Hi,
On Sat, Apr 11, 2009 at 03:03:45PM +0200, Carl Fredrik Hammar wrote:
> On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:
> > Also, I'm not aware of anybody still doing any changes to unionfs
> > :-)
[...]
> Also, in many ways unionfs seems like an good candidate to make use of
>
Hi,
On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote:
> Carl Fredrik Hammar writes:
> > Well it isn't simpler in the sense that we'd need to maintain two
> > very similar yet different code bases. Improvements to one would
> > likely get ported to the other.
[...]
> Also, I'm not a
Hi,
On Fri, Apr 10, 2009 at 07:29:43PM +0300, Sergiu Ivanov wrote:
> writes:
> >settrans veth /hurd/unionfs veth veth,,eth-multiplexer
>
> unionfs has option ``-u'' which tells it to include the underlying
> node in the list of the merged filesystems, so this command should be
> rewritten l
Hi,
On Thu, Apr 09, 2009 at 10:09:04PM +0200, Carl Fredrik Hammar wrote:
> On Wed, Apr 08, 2009 at 07:10:26PM +0200, olafbuddenha...@gmx.net
> wrote:
> > while unionfs must be able to handle an arbitrary number of merged
> > locations, for unionmount it's always exactly two. This simplifies
> > t
olafbuddenha...@gmx.net wrote:
However, it seems to be the source of the most serious bug in my
modified boot.
BUG: After I added the proxy for all RPCs to 'boot', I find that
subhurd sometimes failed to boot. For example, it sometimes stops
booting after the system displays "GNU 0.3 (hurd) (
mremap cannot be defined correctly in terms of mmap and munmap.
It is not in the common GNU API/ABI, only in Linux.
The malloc code is full of HAVE_REMAP conditionals.
Just fix whatever the new case is to properly conditionalize its use.
Thanks,
Roland
Hello!
/home/thomas/tmp/source/glibc/work.new.build.gnu-1/locale/locarchive.o: In
function `file_data_available_p':
/home/thomas/tmp/source/glibc/work.new/locale/programs/locarchive.c:263:
undefined reference to `mremap'
/home/thomas/tmp/source/glibc/work.new.build.gnu-1/locale/locar
13 matches
Mail list logo
