Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > Also, it seems worthwhile to make it possible to have a hole. Maybe you
> > intended that but didn't say. e.g. an object[i] that is MACH_PORT_NULL
> > means a hole at start[i].
>
> Well, I did say it:
>
> "Note that you can specify MACH_PORT_NUL
> I was thinking that they are all appended linearly starting at 0, so the
> offset is implied by the length of the previous objects. If you want to
> create a hole, you must specify this explicitely by adding a hole into the
> list (see below). This makes it simpler because there is no question
On Tue, Dec 03, 2002 at 11:29:46PM +0100, Marcus Brinkmann wrote:
> > In general I don't think the kernel should do a lot of work to make the
> > interface easier for the caller, but the other way around. So special
> > cases for the last element and so forth are questionable.
>
> I think it is
On Tue, Dec 03, 2002 at 05:18:56PM -0500, Roland McGrath wrote:
> > create_proxy (..., memory_object_t object[], vm_prot_t maxprot,
> > vm_size_t start[], vm_size_t end[]);
>
> The crucial parameter you missed is the offset. Each [start_i,end_i) in
> the result corresponds to object
On Tue, Dec 03, 2002 at 05:18:56PM -0500, Roland McGrath wrote:
> > One variant that seems feasible is to simply specify the protection that
> > should apply to all ranges in all objects:
> >
> > create_proxy (..., memory_object_t object[], vm_prot_t maxprot,
> > vm_size_t start[], v
> One variant that seems feasible is to simply specify the protection that
> should apply to all ranges in all objects:
>
> create_proxy (..., memory_object_t object[], vm_prot_t maxprot,
> vm_size_t start[], vm_size_t end[]);
I think that is fine, and keeps it simpler for users. I
Title: New Page 1
ÀÎÅͳݿ¡¼ÀÇ ¼º°øÀÇ °ü°ÇÀº È«º¸
ÀÔ´Ï´Ù!
¡¡
¾Æ¹«¸® ÁÁÀº ȨÆäÀÌÁö¶óµµ ¹æ¹®ÀÚ°¡ ¾ø´Ù¸é ¾Æ¹«¼Ò¿ëÀÌ ¾ø´Ù´Â°ÍÀ» À߾ƽÃÁÒ?
°Ë»ö¿£Áø¿¡ µî·ÏÇÏ·Á¸é ÃÖ¼Ò 10¸¸¿øÀº Áà¾ß ÇÕ´Ï´Ù.
ºñ¿ëÀ» Àý¾àÇÏ¸é¼ È¿°ú¸¦ ±Ø´ëÈÇÒ ¼ö ÀÖ´Â Àß ºÐ·ùµÈ ¸ÞÀϵ¥ÀÌÅÍ°¡ ¿©±â ÀÖ½À´Ï´Ù.
¡¡
>>Á¦°ø ÀÚ·á<<
1. ºÐ·ùµ¥
Hi,
I checked in fatfs 0.4, made it read-only and enabled it in the Makefiles.
It compiles but is not otherwise tested much. But this way everybody can
check themselves, and we can start to treat it like the other Hurd code.
Marco Gerards is still interested in finishing the write support (at l
On Tue, Dec 03, 2002 at 06:52:44PM +0100, Marcus Brinkmann wrote:
> > It calls locale-gen which in turn calls something like
> > localedef -i cs_CZ -c -f UTF-8 cs_CZ.UTF-8
> > which produces the error.
> >
> > libc0.3: /usr/bin/localedef
> > ii libc0.32.3.1-5
>
> I can not reproduce it.
On Tue, Nov 26, 2002 at 08:07:29PM +0100, Michal 'hramrach' Suchanek wrote:
> On Tue, Nov 26, 2002 at 08:18:19AM -0500, Jeff Bailey wrote:
> > On Tue, 2002-11-26 at 05:06, Michal 'hramrach' Suchanek wrote:
> >
> > The locales package is common across all arch's, so this is probably
> > triggering
On Tue, Dec 03, 2002 at 04:48:07AM +0100, Wolfgang Jaehrling wrote:
> On Tue, Dec 03, 2002 at 02:39:06AM -0800, Frank Saar wrote:
> > Hm, well I did.
> > But in the meantime I succeeded in getting a working version (thanks to
> > marcus) and the server is running now as a translator. But in the beg
Hi,
I was reading the libares-patch at
http://hurd.dyndns.org/patches/libares.patch yesterday, and found some
code I think is incorrect. One of the lines goes like this
hostname = (char*)realloc(hostname,sizeof(hostname)*2);
The idea - i think - is to realloc() twice the space previously
allocat
<MÒ>
dq[LÐ
¡ãALð²ó]µÈ¢ûͱ±Ö
(K¸{¶É ȽÌ[AhXÌÝ𨫺³¢j
[EMAIL PROTECTED]
[AhXð²LüµÄ¾³¢B
§104-0061
sæâÀ8-19-3
æ2ECOr@3F
[}KWs
TEL@03-3544-6222
FAX@03-3544-6218
13 matches
Mail list logo
