[¼ºÀα¤°í]ÇÏ·ç¿¡ 30ÆíÀÇ ¼ºÀοµÈ, ¾ßµ¿À» ¹«·á·Î º¸ÀÚ
Title: ÇѸÞÀÏ°ú ¿Ü±¹¸ÞÀÏÀÌ ¾ø´Â ¸ÞÀϸ®½ºÆ® = ÇÏ·ç¿¡ 30ÆíÀÇ ¼ºÀοµÈ, ¾ßµ¿À» ¹«·á·Î º¸ÀÚ = º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù. ´õ ÀÌ»ó ¸ÞÀÏÀ» ¼ö½ÅÇÏ°í ½ÍÁö ¾ÊÀ¸½Ã¸é <¼ö½Å ´ç¿¬È÷ °ÅºÎ>¸¦ Ŭ¸¯ÇØ ÁֽʽÿÀ. Movie Guide¿¡¼ ÇÏ·ç¿¡ 30¿©ÆíÀÇ µ¿¿µ»óÀ» ¹«·á·Î Á¦°øÇÏ°í ÀÖÀ¸´Ï ¸¹Àº ÀÌ¿ë ¹Ù¶ø´Ï´Ù. »çÀÌÆ® ¹Ù·Î°¡±â ¹Ì¼º³âÀÚ Àý´ë ÃâÀÔ±ÝÁö ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
[±¤°í]¿À·ù+Áߺ¹ ¿ÏÀüÁ¦°Å À̸ÞÀÏ 2000¸¸°³¸¦ ´Üµ·4¸¸5õ¿ø¿¡....
±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥¼ÇÎÁß, http://www..com/ ¿¡¼ ¾Ë°Ô µÈ °ÍÀ̸ç, E-Mail ÁÖ¼Ò ¿Ü¿¡, ´Ù¸¥ Á¤º¸´Â °®°í ÀÖÁö ¾Ê½À´Ï´Ù. ¿øÄ¡ ¾ÊÀ¸¸é[¼ö½Å°ÅºÎ]¸¦ ´·¯ÁÖ¼¼¿ä 1. À̸ÞÀϸ¶ÄÉÆÃÀ̶õ? À̸ÞÀϸ¶ÄÉÆÃÀ̶õ ÀÚ½ÅÀÇ »óÇ°°ú ¿¬°üµÈ À̸ÞÀÏ ÁÖ¼Ò¸¦ À̸ÞÀÏ ÁÖ¼Ò¼öÁýÇÁ·Î±×·¥À» ÀÌ¿ëÇØ ¼öÁý, ÆíÁýÇÁ·Î±×·¥À» ÀÌ¿ëÇØ °¡°øÇØ ¹ß¼ÛÇÁ·Î±×·¥À» ÀÌ¿ëÇØ ¹ß¼ÛÇÏ´Â °ÍÀÔ´Ï´Ù. ±âÁ¸ÀÇ ´ë±â¾÷µéÀº ¼öõ¸¸¿ø¿¡ ¼ö¾ï¿ø¾¿ÇÏ´Â CRM ½Ã½ºÅÛÀ» ÀÌ¿ëÇØ À̸ÞÀϸ¶ÄÉÆÃÀ» ÇßÀ¸¸ç ÇöÀç±îÁö ³ª¿Â ¸¶ÄÉÆà ¹æ¹ýÁß °¡Àå È¿°úÀûÀÎ ¹æ¹ýÀÔ´Ï´Ù. 2. E-mail ±¤°í°¡ ÁÖ´Â È¿°ú e-mailÀ» ÀÌ¿ëÇÑ ¸¶ÄÉÆÿ¡´Â ´Ü¼ø±¤°í, ȨÆäÀÌÁö ¹æ¹®À¯µµ , ¼³¹®Á¶»ç, ÆǸű¤°íµî ±¤°íÁÖÀÇ ¿ä±¸¿¡ ÀÇÇÑ ´Ù¾çÇÑ ÇüÅÂ¿Í ¸ñÀûÀÌ ÀÖÀ» ¼ö ÀÖ½À´Ï´Ù. ÀÎÅͳݹè³Ê±¤°í ¹× ¿ìÆí¹°±¤°í¿Í ºñ±³ÇÏ¿´À» ¶§ ÃÖ¼Ò 10¹è¿¡¼ ÃÖ´ë 30¹è ÀÌ»óÀÇ ³ôÀº ±¤°íÈ¿°ú ÀÔÁõ 3. À̸ÞÀϸ¶ÄÉÆÃÀ¸·Î ¼öÀÍÀ» ¿Ã¸± ¼ö Àֳı¸¿ä? È®½ÇÇÑ ¾ÆÀÌÅÛ(ÀûÁ¤¸¶Áø°ú ŸÄÏÀ» °í·Á)°ú ¼¹ö·Î±×ºÐ¼®À¸·Î ÃæºÐÇÑ ¼öÀÍÀ» ¿Ã¸± ¼ö ÀÖ½À´Ï´Ù. ÇöÀç ¹ýÀû, »çÀ̹öȯ°æÀûÀ¸·Î ÀÌ Àú·ÅÇÏ°í, È¿°úÀûÀÎ ¸¶ÄÉÆÃÀÇ ±âȸ°¡ ¾ó¸¶³²Áö ¾Ê¾Ò½À´Ï´Ù. ´õÀÌ»ó ´ÊÁö ¸¶¼¼¿ä. ±¤°í¸ÞÀÏÀû¿ë»ç·Ê( Case study) ¤¡. ÇÚµåÆù : ¹ß¼ÛÀϼö 2ÀÏ , ÆǸÅÀ² 150´ëÀÌ»ó ÀáÀç°í°´ À¯Ä¡ ¹× È®º¸ ¤¤. Ä¿Çøµ : ¹ß¼ÛÀϼö 1ÀÏ, ÆǸÅÀ² 30¸µÀÌ»ó ÀáÀç°í°´ À¯Ä¡ ¹× È®º¸ ¤§. MP3 À̺¥Æ® ÇÁ·Î¸ð¼Ç : ¹ß¼ÛÀϼö 2ÀÏ ,80´ëÀÌ»ó ÀáÀç°í°´ À¯Ä¡ ¹× È®º¸ ¤©. ħ´ë°¡±¸ : ¹ß¼ÛÀϼö 5ÀÏ ÆǸÅÀ² 50´ëÀÌ»ó , ÀáÀç°í°´ À¯Ä¡ ¹× È®º¸ ¤±. ¼ºÀιæ¼Û: ¹ß¼ÛÀÏ È¸¿øÀ¯Ä¡ 300¸í ..µîµî - ºÎ½ÇÇѸÞÀÏ ¿Ïº®Á¤¸® - ¿ÏÀüÁ¦°Å µÈ ¾çÁúÀÇ ¸ÞÀÏ 2000¸¸°³¸¦ ´Üµ· 4¸¸5õ¿ø¿¡ µå¸³´Ï´Ù . - ´ë·®¸ÞÀÏ ¹ß¼ÛÇÁ·Î±×·¥(·¹µå½ºÆÄÀÌ´õ, ÀÌÁö¸ÞÀÏ)Àº Èñ¸ÁÀÚ¿¡ ÇÑÇÏ¿© À̸ÞÀϸ®½ºÆ®¿Í °°ÀÌ »ç½Ã¸é ÇÕÇؼ 8¸¸¿ø ¹ß¼ÛÇÁ·Î±×·¥¸¸ »ç½Ç °æ¿ì¿¡´Â 5¸¸¿ø¿¡ µå¸®°Ú½À´Ï´Ù. ´Ü ¸î½Ã°£À̸é È¿°ú¸¦º¸´Â À̸ÞÀÏ ±ÍÇÏÀÇ ¼º°øÀ» º¸ÀåÇÕ´Ï´Ù. ÀÌ°¡°ÝÀ¸·Î´Â ¾ÕÀ¸·Î ±âȸ°¡ ¾øÀ»°ÍÀÔ´Ï´Ù °ü½É¶Ç´Â Áú¹® ÀÖÀ¸½Å ºÐµéÀº ¸ÞÀÏÁÖ¼¼¿ä Email: [EMAIL PROTECTED] Copyright ¨Ï1991-2002 Mail Marketing Corporation. All rights reserved. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
boot broken
Hi,
Roland, you should learn to type some day. We don't have an
I386_THREAD_STATE macro, but we do have an i386_THREAD_STATE
one. Here is the fix (no log entry).
--- boot.c.~1.105.~ Wed May 29 16:28:38 2002
+++ boot.c Sat Jun 1 12:24:20 2002
@@ -381,7 +381,7 @@ boot_script_exec_cmd (void *hook,
stack_end - trunc_page ((vm_offset_t) arg_pos));
thread_create (task, &thread);
-#ifdef I386_THREAD_STATE
+#ifdef i386_THREAD_STATE
{
struct i386_thread_state regs;
reg_size = i386_THREAD_STATE_COUNT;
Cheers,
--
Alfred M. Szmidt
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Debugging help
I've experienced a few more or less reproducible hangs on Neal's Hurd box (dryden). One example: I telnet in to the box. Start screen. Start emacs. Type M-x man RET non-existing-command RET. Then emacs displays a message saying that the man page can't be found, and then I lose contact with both emacs and screen. Logging in again, killing the hanging processes, and running screen -ls gives nisse@dryden:~$ screen -ls There is a screen on: 6098.ttyp0.dryden (Dead ???) Remove dead screens with 'screen -wipe'. 1 Socket in /var/run/screen/S-nisse. so appearantly, screen just died. In another case, lsh-make-seed hanged, typing ^C didn't work, and I also lost contact with my screen. I logged in again from a different xterm, and killed the lsh-make-seed process, but I still didn't get back to the shell where it was started. Hmm, I'm now trying lsh-make-seed -v --trace --debug, and from the output, it seems that it hangs in poll. And it's not interruptable with ^C. This report is somewhat unstructured, so I guess my question is: How do I get more information about the failing processes, so I can file useful bug reports? /Niels ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Debugging help
Try attaching gdb to the evil process and see if you can get something useful from a back-trace or set some break points here and there to see where it fails. -- Alfred M. Szmidt ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: 16 bit UIDs
Thomas Bushnell, BSG <[EMAIL PROTECTED]> wrote: > One idea is just a straightforward file somewhere in the filesystem > that holds an index of inode numbers and UIDs. Will we use 64-bit UIDs on 64-bit systems? If so, we should use 64 bit wide UID fields on 32-bit machines as well, thus staying compatible, right? Cheers, GNU/Wolfgang -- Wolfgang Jährling <[EMAIL PROTECTED]> \\ http://stdio.cjb.net/ Debian GNU/Hurd user && Debian GNU/Linux user \\ http://www.gnu.org/ The Hurd Hacking Guide: http://www.gnu.org/software/hurd/hacking-guide/ ["We're way ahead of you here. The Hurd has always been on the] [ cutting edge of not being good for anything." -- Roland McGrath ] ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
[±¤°í] ÆмÇÀÇ Â÷º°È "INFASHION"
Title: ÆмÇÀÇ Â÷º°È "infashion" º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù. ¼ö½Å°ÅºÎ ¹öÆ°À» Ŭ¸¯ÇÏ½Ã¸é ¼ö½Å°ÅºÎ󸮰¡ ÀÌ·ç¾î Áý´Ï´Ù. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
[±¤°í] ÆмÇÀÇ Â÷º°È "INFASHION"
Title: ÆмÇÀÇ Â÷º°È "infashion" º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù. ¼ö½Å°ÅºÎ ¹öÆ°À» Ŭ¸¯ÇÏ½Ã¸é ¼ö½Å°ÅºÎ󸮰¡ ÀÌ·ç¾î Áý´Ï´Ù. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Litoo's newsletter
Title: Litoo's letter Litoo's letter (June, 2002) Quick search (author, title or commentary) Letter FREE Email: Register Unregister (Si vous souhaitez recevoir notre lettre en français, voyez notre page réservée à notre lettre d'information.) New releases No new release in english this month. Therefore, we advise you to go and have a look to our french letter on http://www.litoo.com/lettre/france/lettrelitoo200206.htm Notes Wishing to develop us abroad where we already have several contacts in the French-speaking and the English-speaking world, our commercial management was the object of a light reorganization to take into account the euroland and the laws on exportation. We remind our foreign friends that the lowest shipping cost for a shipping by air mail or by boat is that of the cubic meter ( 260 Euros). Just have a look to our page at http://www.litoo.com/anglais/librairie.asp We grant important discounts for booksellers, these being able to increase according to the volume. Please , take advantage of the basket which offers you Litoo to increase your brilliance. Several catalogs are available on the following address: http://www.litoo.com/anglais/tele.asp If you wish a more specific catalog, we can make it for you. Please, ask for it. Translation in Italian, Portugese, ... We look for translators for the translation of our web site in Italian, Portugese, The translation will give you right to a payment in books for an amount about 500 EUR. This work is very well paid according to the power of the on-line translators proposed on http://www.softissimo.com It is more a second reading than a real translation. Write us at [EMAIL PROTECTED]; if you are interested. It is a home work.. Be our camelots You are journalist, manager of a magazine, radio, television; you organise with Litoo some articles and emissions about our books and works. Litoo 's managers will be pleased to answer your propositions. You know a bookshop or a bookstore and they don't have even one of our books. Tell them just to contact us to solve this little mistaken. Our activity of Bookseller and publisher allows us either to publish our own books, either to sell the books of other publishers. Please ask for a cost estimation. We do precise that the language of the book is not a problem for us. For webmasters, see our page for downloads. A banner is disponible to put a link on your page. To help us in the diffusion of this letter, tell your friends to subscribe. (go to our special page for our newsletter) Download our catalog from our web. If you wish to receive our paper catalog sorted by title or by author or by category, just send a mail to us. © Group Saint-Remi SARL of a 10066 Euros capital n° Siren: 440397347 Litoo.com International Bokkseller-Publisher BP 79 33410 Cadillac FRANCE Tel / Fax: 0556767480 This message has been sent to the following address: [EMAIL PROTECTED]To unregister, please use the form of our web site and specify this address ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
libiohelp
Hey,
I tried to compile the Hurd, and it failed on libiohelp. I can't remember
the error message, but here is the fix. It wanted the declarations before
the definitions of the functions.
James A. Morrison
2002-06-01 James A. Morrison <[EMAIL PROTECTED]>
* shared.c: Move function declarations ahead of the functions
definitions.
Index: shared.c
===
RCS file: /cvsroot/hurd/hurd/libiohelp/shared.c,v
retrieving revision 1.1
diff -u -r1.1 shared.c
--- shared.c18 Nov 1996 23:48:14 - 1.1
+++ shared.c1 Jun 2002 17:01:13 -
@@ -1,5 +1,5 @@
/* Default functions
- Copyright (C) 1996 Free Software Foundation
+ Copyright (C) 1996,2002 Free Software Foundation
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
@@ -19,6 +19,10 @@
#include "iohelp.h"
/* These definitions exist to satisfy the linker. */
+void
+iohelp_fetch_shared_data (void *foo) __attribute__ ((weak));
+void
+iohelp_put_shared_data (void *foo) __attribute__ ((weak));
void
@@ -32,10 +36,3 @@
{
abort ();
}
-
-
-void
-iohelp_fetch_shared_data (void *foo) __attribute__ ((weak));
-void
-iohelp_put_shared_data (void *foo) __attribute__ ((weak));
-
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: libiohelp
* James A Morrison writes: > I tried to compile the Hurd, and it failed on libiohelp. I can't remember > the error message, but here is the fix. It wanted the declarations before > the definitions of the functions. Could you try to get the error message? I don't think that this should cause any errors. Cheers, -- Alfred M. Szmidt ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: vm_size_t is unsigned, so libps should use unsigned ints.
--- Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > On Thu, May 30, 2002 at 08:22:12PM -0700, James Morrison wrote: > > Nothing else used ps_emit_nice_int. > > Oh, right, I was confused. > > > I don't like this. After looking at both sprint_frac_value and > > ps_emit_nice_int I think they should both use size_t's. > > Yeah, seems so. I will look again at it tomorrow. > > Thanks, > Marcus > I think there needs to be a new function ps_cmp_size_t. But it would look exactly like ps_cmp_float and ps_cmp_int. The easiest way I can see to do this is a macro #define COMPARE (type) ps_cmp_type ... Will this work? = James Morrison University of Waterloo Computer Science - Digital Hardware 2A co-op http://hurd.dyndns.org Anyone referring to this as 'Open Source' shall be eaten by a GNU __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
tmpfs/dir.c:223
Could someone please revert the changes made to tmpfs/dir.c:223. Line 223 currently has a call to diskfs_lookup_cached with 3 arguments. = James Morrison University of Waterloo Computer Science - Digital Hardware 2A co-op http://hurd.dyndns.org Anyone referring to this as 'Open Source' shall be eaten by a GNU __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: libiohelp
--- "Alfred M. Szmidt" <[EMAIL PROTECTED]> wrote: > * James A Morrison writes: > > I tried to compile the Hurd, and it failed on libiohelp. I can't > remember > > the error message, but here is the fix. It wanted the declarations before > > the definitions of the functions. > > Could you try to get the error message? I don't think that this > should cause any errors. > > Cheers, > -- > Alfred M. Szmidt gcc -O -Wall -g -O2 -I. -I../../libiohelp -I.. -I../.. -I../../include -D_GNU_SOURCE -D_IO_MTSAFE_IO -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1 -c -o shared.o ../../libiohelp/shared.c ../../libiohelp/shared.c:26: weak declaration of `iohelp_fetch_shared_data' must precede definition ../../libiohelp/shared.c:32: weak declaration of `iohelp_put_shared_data' must precede definition make: *** [shared.o] Error 1 = James Morrison University of Waterloo Computer Science - Digital Hardware 2A co-op http://hurd.dyndns.org Anyone referring to this as 'Open Source' shall be eaten by a GNU __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: tmpfs/dir.c:223
* James Morrison writes: > Could someone please revert the changes made to tmpfs/dir.c:223. Line 223 > currently has a call to diskfs_lookup_cached with 3 arguments. This was already reported [1] but not fixed probably due because of me being unclear. :) [1]: http://mail.gnu.org/pipermail/bug-hurd/2002-May/008805.html Cheers, -- Alfred M. Szmidt ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
should libstore be linked against libthreads.
Hi,
I was having trouble compiling storeinfo, storecat, and storeread. I was
getting the following error:
jim@lazarus:~/cvs/hurd/build/utils$ make storecat
gcc -O
-Wl,-rpath-link=.:../libdiskfs/:../libfshelp/:../libftpconn/:../libhurdbugaddr/:../libihash/:../libiohelp/:../libnetfs/:../libpager/:../libpipe/:../libports/:../libps/:../libshouldbeinlibc/:../libstore/:../libthreads/:../libtrivfs/
-Wall -g -O2 -uargp_program_bug_address -o storecat \
storecat.o \
'-Wl,-(' ../libhurdbugaddr/libhurdbugaddr.so ../libstore/libstore.so
../libshouldbeinlibc/libshouldbeinlibc.so \
\
'-Wl,-)'
../libstore/libstore.so: undefined reference to `cthread_stack_mask'
collect2: ld returned 1 exit status
make: *** [storecat] Error 1
I added threads to HURDLIBS in libstore/Makefile and this fixes the problem.
I don't know why this has shown up now, but I think libstore should be linked
to libthreads since gunzip, part, and unzipstore all include .
=
James Morrison
University of Waterloo
Computer Science - Digital Hardware
2A co-op
http://hurd.dyndns.org
Anyone referring to this as 'Open Source' shall be eaten by a GNU
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: should libstore be linked against libthreads.
That was libthreads bugs I introduced recently while doing the merge there. I've checked in the fixes to libthreads, and everything will be recompiled. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
[ ±¤ °í ] ÈÞ´ëÆù ¿©±â¼ »ç¼¼¿ä ¿©±ä°ÅÀÇ °øÂ¥¿¹¿ä.À̺¥Æ®Áß~
Title: Angel PCS ±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥¼ÇÎ Áß ¹ß°ßÇÏ¿´À¸¸ç E-mail ÁÖ¼Ò¿Ü¿¡ ´Ù¸¥ Á¤º¸´Â °®°íÀÖÁö ¾Ê½À´Ï´Ù. Á¤ÅëºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó°í Ç¥±âÇÑ ¸ÞÀÏÀÔ´Ï´Ù. ¿øÄ¡ ¾ÊÀ¸¸é [¼ö½Å°ÅºÎ]¸¦ ´·¯ÁÖ¼¼¿ä. ¾È³çÇϼ¼¿ä. [angelpcs.co.kr] ÀÔ´Ï´Ù. ¸ðµç ±âÁ¾ÀÇ ÈÞ´ëÆùÀ» *¿ø°¡*¿¡ °ø±ÞÇص帳´Ï´Ù. Copyright ¨Ï 2002 Hoam-net. All rights reserved. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
¾È³çÇϽʴϱî!! ¿À·¡°£¸¸ÀÔ´Ï´Ù!!! ¢½
Title: ¢Ñ ¼ºÀÎ Á¾ÇÕ ¿£ÅÍÅ×ÀθÕÆ® ¼½½ºÀ£ ÄÚ¸®¾Æ ´åÄÄ. ¢Ð ¢Ñ ±ÍÇÏÀÇ À̸ÞÀÏ ÁÖ¼Ò´Â ÀÏ¹Ý °Ô½ÃÆÇ¿¡¼ °ËÃâµÈ °ÍÀÌ¸ç ±ÍÇÏÀÇ À̸ÞÀÏ ÁÖ¼Ò ¿Ü¿¡´Â ¾î¶°ÇÑ È¸¿ø Á¤º¸µµ °®°í ÀÖÁö ¾Ê½À´Ï´Ù. ¢Ð ¢Ñ¢Ñ ¹«·á. ¹«»èÁ¦. ³ë¸ðÀÚÀÌÅ©. ¢Ð ¿ÏÀü 100% ¹«·á. ¼ºÀÎ ¿µÈ. ¼ºÀÎ °Ö·¯¸®. ¼ºÀÎ Ç÷¹½¬. Á¤¾ç °Ö·¯¸®. ÆäƼ½¬ °Ö·¯¸®. ÈÁ¦ÀÇ ºñµð¿À. ¢º À§ À̹ÌÁö¸¦ Ŭ¸¯ÇÏ¸é ¹Ù·Î °¥¼öÀÖ½À´Ï´Ù. ÀÌ ¸ÞÀÏÀ» ¿øÄ¡ ¾ÊÀ¸¸é ±ÍÇÏÀÇ À̸ÞÀÏ µµ±¸¿¡¼ ¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇϽʽÿä. ¢º http://www.sexwelkorea.com. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: 16 bit UIDs
Wolfgang Jährling <[EMAIL PROTECTED]> writes: > Thomas Bushnell, BSG <[EMAIL PROTECTED]> wrote: > > One idea is just a straightforward file somewhere in the filesystem > > that holds an index of inode numbers and UIDs. > > Will we use 64-bit UIDs on 64-bit systems? If so, we should use 64 bit > wide UID fields on 32-bit machines as well, thus staying compatible, > right? The width has to be the same everywhere. There *are* more people in the world than fit in a 32-bit UID, but I'm not sure that's a factor. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
netfs part of a console server with server-client model
Hi, as discussed before, it is desirable to have a server-client model for the console: VISUAL DISPLAY I \ / VISUAL DISPLAY II | | TERM ON VIRTUAl CONSOLE I ... > CONSOLE SERVER < TERM ON VIRTUAL CONSOLE II INPUT DEVICE I | | ... INPUT DEVICE II| | ... / \ The console server provides an abstract hardware console in the local encoding to the term server on the one hand, and on the other hand it provides two interfaces for user interaction: 1. The display interface, which is basically a map'able file which contains the text buffer and attribute (color, blinking, etc) matrix with the possibility for the user to receive asynchronous update information on the content. This also includes bells and gimmicks like this. 2. The input interface, which allows a kbd driver, mouse gestures, voice recognition software etc to input keyboard and similar events into the console server. This side of the interface will be UCS-4/UTF-8 based only. It is expected that usually, both parts are combined into a single program. This program also handles virtual console switching etc. See past discussion for details on what features this design makes possible. Please see also past discussion about what difficulties are in the design of the asynchronous update interface :) I gave a huge list, and did not make progress on that part yet. I guess experimentation will help a lot. (BTW, the Linux braille terminal driver polls the screen every so and so often, because there are no file change notifications, we should be able to do better than that). What I attach to this mail is a file that incorporates some the virtual console abstraction in console/console.c in the Hurd source tree, and new parts which provide a netfs based filesystem that looks like this: console: drwxrwx---2 root root0 2. Jun 04:27 1/ drwxrwx---2 root root0 2. Jun 04:27 3/ drwxrwx---2 root root0 2. Jun 04:27 4/ 1: crw-rw1 root root0, 0 2. Jun 04:27 console -rw-rw1 root root 2000 2. Jun 04:27 display 3: crw-rw1 root root0, 0 2. Jun 04:27 console -rw-rw1 root root 2000 2. Jun 04:27 display 4: crw-rw1 root root0, 0 2. Jun 04:27 console -rw-rw1 root root 2000 2. Jun 04:27 display The idea is that here are three virtual consoles provided by the server, with the IDs 1, 3 and 4. The "console" node in each directory provided by the server is for term, and the "display" node is for the display/input driver (better names are welcome). 2000 is 80x25 and the default size of a screen, this is just an example. I am inclined to give all virtual consoles for one console the same size and local encoding, but this is not terribly important. Nothing of this is set in stone, in particular the interface between the console server and the display driver. However, I think it might be a good idea to start with a simplicistic interface based on existing RPCs, and work from there. I think this is better than putting a lot of work into getting the existing code base with the old, monolithic design to make it functional. I have found a good description of xkb, btw, and will go for that. It just needs some time, and it might be better to write a clean console server, and a not-so-clean display and input driver so oskit-mach becomes usable, and then go from there. Anyway, the point of this mail is to put the netfs code into public. This is the first netfs based filesystem I wrote, and I took some of the code from hostmux (found a bug in there, too). The internals are like this: Virtual consoles are created on the fly when looking up nodes in root. This is unproblematic, as only available consoles are listed in netfs_get_dirents, and usually programs will work with that. Probably some parts of the virtual console should be allocated lazily, so you don't hit the full cost just to look up a node you don't want. A virtual console structure is also the place where created nodes are looked up. This safes the inode hash table. For this to work, each node has to keep a reference to the virtual console, and the virtual console have to back reference to the node (but without acquiring a reference to it). netfs_node_norefs removes the back reference before releasing the ref to the virtual console. Locking is a bit peculiar, but not really difficult, as the virtual console structure itself is fine-graded. All this is exactly how hostmux stores and references the node and hostname structures. The code is tested and works as far as it is there. It has one serious limitation, and that is the lookup of .., which currently assumes a flat hierarchy (only one level of subdirectories). It doesn't integrate all too much with the virtual console code, either, some comments show
