> On Sat, Apr 22, 2000 at 02:20:30AM +0200, Marcus Brinkmann wrote:
> >
> > I have troble with current CVS version, cross compiled with gcc 2.95.2 and
> > glibc 2.1.3 (as of 2000/02/24). When booting, I get:
The changes I made related to versioning went into glibc (2.2) on
2000-03-30 or thereabo
On Sat, Apr 22, 2000 at 02:20:30AM +0200, Marcus Brinkmann wrote:
>
> I have troble with current CVS version, cross compiled with gcc 2.95.2 and
> glibc 2.1.3 (as of 2000/02/24). When booting, I get:
>
> Hurd server bootstrap: ext2fs.static[hd2s3] execext2fs.static:
>../../libdiskfs/boot-start.
On Sat, May 13, 2000 at 04:07:04PM -0400, Thomas Bushnell, BSG wrote:
>
> > 2. Storing the location of the directory entry:
> > This is not constant under rename operations, thus it fails to fulfill
> > requirement two.
> > We could reflect this by changing the node cache, but we can't change the
Kalle Olavi Niemitalo <[EMAIL PROTECTED]> writes:
> According to the glibc manual, the result of setjmp must not be
> assigned like diskfs_catch_exception does: it must be either
> immediately used in a do/while/for/if/switch statement or
> ignored. Has GCC relaxed this restriction?
Blech. Any
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> is pager_unlock_page just called to make it possible for a fs to prepare for
> an actual pager_write_page on the page? It doesn't look as if I need to do
> anything except to make sure that following writes will succeed.
pager_unlock_page is called
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Do you have any other tips for this situation, things to watch out for, or
> strategies how to get the location of the directory entry (seems I need a
> lookup at update time, because the address is not robust under rename
> operations (moving the fi
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Do I need some lock on the directory node when updating the node
> information?
Yes, I think that would be necessary. But only when you actually
write it out to disk, in the diskfs_write_disknode routine. Just
acquire the regular directory lock.
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> 1. Storing the beginning of the file on disk:
> This is a workable solution as long as you don't have zero bytes file, which
> don't have a unique beginning of the file (for example, start_cluster for
> all FAT zero files is cluster 0). So, this viol
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> np->allocsize is the number of bytes allocated for the file, right? (rounded
> up to a block multiple).
>
> Is it okay for np->allocsize to be initially as big as needed to contain the
> file, rather than the actual disk space allocated for the file
