freebsd-current@freebsd.org
$B$"$C$?$+$$29$b$j;}$C$F$^$9$+!)(B
$B4($$?4$rKd$a$F$/$l$k$=$s$J=P2q$$$,$3$3$K$O$"$j$^$9!#(B
$B$?$a$7$K$"$J$?$N5$;}$A$r=q$-9~$s$G$4$i$s(B
$B4j$$$O$+$J$i$:3p$$$^$9$h!*(B
Http://www.if-j.net
$B=P2q$$7O%5%$%H!V%$%U!W$G$9!#(B
$B$"$J$?$KKbK!$r%F%/%^%/%^%d%3%s{(B
$B=w@-L5NA$5$i$K%-%c%C%7%g%P%C%/!*(B
$BCK@-$b#3#0%]%$%s%HL5NACf!*(B
$B7HBSEEOC$+$4<+Bp$NEEOCHV9f$GEPO?$7$F$/$@$5$$!#(B
$B%"%I%l%9EyHs8x3+$G$9$N$G0B?4$7$F$4MxMQ$/$@$5$$!#(B
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Greg Lehey wrote: > Since then, it has become possible for the loader to load modules > before booting the kernel. This means that, theoretically, it would > be possible to have a JFS root file system. Given the strong > opposition to the GPL in some factions of the FreeBSD project, I don't > see this happening any time soon, especially since we still don't know > if it will buy us anything. ? OK, I load the kernel from the JFS. I mount the root FS, which is a JFS. I read the module "jfs.ko" from the JFS so that I can mount the root FS, which is a JFS, so I can read the module "jfs.ko" from the JFS so that I can mount the root FS, which is a JFS, so I can read the module "jfs.ko" from the JFS so that I can mount the root FS, which is a JFS, so I can... Do you see the problem yet? > >> It is used on IBM MainFrames and Enterprise servers > >> for high performance and maximum throughput... > > > > No, it's not. The Linux JFS is derived from the OS/2 JFS code, not > > the good AIX JFS code. > > That's correct, but note that AIX is moving to this code base too, so > it's not as if it's second-rate. From what I've seen of the > structures, JFS2 is *much* better than JFS1. I haven't compared > performance. None of the Web Connections RS/6000 machines ran this OS/2 derived code. I was under the impression that it was there for Linux compatability. My impression is, layout or not, the original JFS is much better code, overall. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Terry Lambert wrote: > > Greg Lehey wrote: > > Since then, it has become possible for the loader to load modules > > before booting the kernel. This means that, theoretically, it would > > be possible to have a JFS root file system. Given the strong > > opposition to the GPL in some factions of the FreeBSD project, I don't > > see this happening any time soon, especially since we still don't know > > if it will buy us anything. > > ? > > OK, I load the kernel from the JFS. I mount the root FS, which > is a JFS. I read the module "jfs.ko" from the JFS so that I can > mount the root FS, which is a JFS, so I can read the module "jfs.ko" > from the JFS so that I can mount the root FS, which is a JFS, so I > can read the module "jfs.ko" from the JFS so that I can mount the > root FS, which is a JFS, so I can... > > Do you see the problem yet? Libstand (and hence the loader) could be extended to allow reading files from jfs without using any GPL'ed code. For example our loader can load modules from the FAT even though we do not have any M$ code. :) Alternatively, /boot could be placed on separate filesystem, which could be ufs or anything else supported by the loader. -Maxim > > >> It is used on IBM MainFrames and Enterprise servers > > >> for high performance and maximum throughput... > > > > > > No, it's not. The Linux JFS is derived from the OS/2 JFS code, not > > > the good AIX JFS code. > > > > That's correct, but note that AIX is moving to this code base too, so > > it's not as if it's second-rate. From what I've seen of the > > structures, JFS2 is *much* better than JFS1. I haven't compared > > performance. > > None of the Web Connections RS/6000 machines ran this OS/2 derived > code. I was under the impression that it was there for Linux > compatability. My impression is, layout or not, the original JFS > is much better code, overall. > > -- Terry > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: kernel trap doesn't have ucred
Hi,
I get a panic "kernel trap doesn't have ucred" when I try to install
Linux ORACLE 8.1.7.
The ORACLE installation program is a JAVA application and only seems
to work with the included JRE (the IBM 1.1.8 JRE according to the
LICENSE file).
The JRE is using native Linux threads, and I know I the FreeBSD
linuxulator doesn't completely support Linux threads. It shouldn't
panic, however.
-current was CVSuped on 12/6 at 6 p.m. CET.
Any clues from the stack trace below? Anything else I should provide?
--
Regards,
Georg.
hunter# gdb -k /usr/obj/usr/src/sys/HUNTER/kernel.debug vmcore.5
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 4333568
initial pcb at 330560
panicstr: kernel trap doesn't have ucred
panic messages:
---
panic: kernel trap doesn't have ucred
panic: kernel trap doesn't have ucred
Uptime: 9h57m30s
dumping to dev ad0s2b, offset 2000128
dump ata0: resetting devices .. done
1023 1022 1021 1020 (--snip--)
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492
492 if (!dodump)
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492
#1 0xc019b6e3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:335
#2 0xc019bb1d in panic (fmt=0xc02dfec0 "kernel trap doesn't have ucred")
at /usr/src/sys/kern/kern_shutdown.c:634
#3 0xc0296660 in trap (frame={tf_fs = 24, tf_es = -1070792688, tf_ds = 16,
tf_edi = 0, tf_esi = 256, tf_ebp = -570946320, tf_isp = -570946352,
tf_ebx = 514, tf_edx = -1070159328, tf_ecx = 0, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1071077920, tf_cs = 8,
tf_eflags = 70, tf_esp = -1070736513, tf_ss = -1070870117})
at /usr/src/sys/i386/i386/trap.c:412
#4 0xc028a5e0 in Debugger (msg=0xc02bd19b "panic") at machine/cpufunc.h:63
#5 0xc019bb08 in panic (fmt=0xc02dfec0 "kernel trap doesn't have ucred")
at /usr/src/sys/kern/kern_shutdown.c:621
#6 0xc0296660 in trap (frame={tf_fs = -1072168945, tf_es = -1088487377,
tf_ds = -1071120337, tf_edi = -1088422624, tf_esi = 3,
tf_ebp = -1088422712, tf_isp = -570946200, tf_ebx = 17, tf_edx = 16,
tf_ecx = -1088422668, tf_eax = 3, tf_trapno = 9, tf_err = 28,
tf_eip = -1071071377, tf_cs = 8, tf_eflags = 65666, tf_esp = 673044849,
tf_ss = 31}) at /usr/src/sys/i386/i386/trap.c:412
#7 0xc028bf6f in doreti_iret ()
#8 0x281dd9d4 in ?? ()
#9 0x281dc55a in ?? ()
#10 0x2807feca in ?? ()
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Terry Lambert wrote: > Greg Lehey wrote: > > Since then, it has become possible for the loader to load modules > > before booting the kernel. This means that, theoretically, it would > > be possible to have a JFS root file system. Given the strong > > opposition to the GPL in some factions of the FreeBSD project, I don't > > see this happening any time soon, especially since we still don't know > > if it will buy us anything. > > ? > > OK, I load the kernel from the JFS. I mount the root FS, which > is a JFS. I read the module "jfs.ko" from the JFS so that I can > mount the root FS, which is a JFS, so I can read the module "jfs.ko" > from the JFS so that I can mount the root FS, which is a JFS, so I > can read the module "jfs.ko" from the JFS so that I can mount the > root FS, which is a JFS, so I can... > > Do you see the problem yet? It is not a problem. The *kernel* does not load jfs.ko, it is loader itself. There is no reason why a trivial non-gpl jfs reader couldn't be written for boot2 and loader if the need was great enough. Or have /boot as a seperate file system (eg: UFS or FAT32). We do this on IA64 where /boot is a FAT32 filesystem (not exactly, but close enough. I usually mount it on /efi and make /boot/ a symlink to /efi/boot so that in EFI we have a /boot as well). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
__xuname gone AWOL?
Hi folks, Since last week, I'm having trouble compiling one of the utilities supplied with Exim, which calls uname(): gcc -O -pipe -march=pentiumpro -march=pentiumpro \ -o exim_lock exim_lock.c -lcrypt -lpam /tmp/cc2YeHtC.o: In function `main': /tmp/cc2YeHtC.o(.text+0x50d): undefined reference to `__xuname' *** Error code 1 __xuname.c is still included in SRCS in src/lib/libc/gen/Makefile.inc, but the symbol isn't in my installed libc. Any ideas? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: __xuname gone AWOL?
On Tuesday 11 December 2001 11:17 am, Sheldon Hearn wrote: > Hi folks, > > Since last week, I'm having trouble compiling one of the utilities > supplied with Exim, which calls uname(): > > gcc -O -pipe -march=pentiumpro -march=pentiumpro \ > -o exim_lock exim_lock.c -lcrypt -lpam > /tmp/cc2YeHtC.o: In function `main': > /tmp/cc2YeHtC.o(.text+0x50d): undefined reference to `__xuname' > *** Error code 1 > > __xuname.c is still included in SRCS in > src/lib/libc/gen/Makefile.inc, but the symbol isn't in my installed > libc. On a complete different application, but similar problem. KDE Konqueror on -CURRENT also crashes because of this. > Any ideas? > > Ciao, > Sheldon. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Dominic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Maxim Sobolev wrote: > > OK, I load the kernel from the JFS. I mount the root FS, which > > is a JFS. I read the module "jfs.ko" from the JFS so that I can > > mount the root FS, which is a JFS, so I can read the module "jfs.ko" > > from the JFS so that I can mount the root FS, which is a JFS, so I > > can read the module "jfs.ko" from the JFS so that I can mount the > > root FS, which is a JFS, so I can... > > > > Do you see the problem yet? > > Libstand (and hence the loader) could be extended to allow reading > files from jfs without using any GPL'ed code. For example our loader > can load modules from the FAT even though we do not have any M$ code. > :) Alternatively, /boot could be placed on separate filesystem, which > could be ufs or anything else supported by the loader. Patches appreciated. Note that if you do a read-only JFS, you are more than half way there to a n0n-GPL'ed implementation, so you might as well finish it off, instead of porting the IBM code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Peter Wemm wrote: > It is not a problem. The *kernel* does not load jfs.ko, it is loader > itself. There is no reason why a trivial non-gpl jfs reader couldn't be > written for boot2 and loader if the need was great enough. Or have /boot > as a seperate file system (eg: UFS or FAT32). We do this on IA64 where > /boot is a FAT32 filesystem (not exactly, but close enough. I usually > mount it on /efi and make /boot/ a symlink to /efi/boot so that in EFI > we have a /boot as well). JFS patches? Sysinstall patches? /usr/src/lib/stand patches? /usr/src/sys/boot/* patches? 8^). --- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote:
> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote:
> >
> >>> performance without it - for reading OR writing. It doesn't matter
> >>> so much for RAID{1,10}, but it matters a whole lot for something like
> >>> RAID-5 where the difference between a spindle-synced read or write
> >>> and a non-spindle-synched read or write can be upwards of 35%.
> >>
> >> If you have RAID5 with I/O sizes that result in full-stripe operations.
> >
> > Well, 'more then one disk' operations anyway, for random-I/O. Caching
> > takes care of sequential I/O reasonably well but random-I/O goes down
> > the drain for writes if you aren't spindle synced, no matter what
> > the stripe size,
>
> Can you explain this? I don't see it. In FreeBSD, just about all I/O
> goes to buffer cache.
>
> > and will go down the drain for reads if you cross a stripe -
> > something that is quite common I think.
>
> I think this is what Mike was referring to when talking about parity
> calculation. In any case, going across a stripe boundary is not a
> good idea, though of course it can't be avoided. That's one of the
> arguments for large stripes.
In a former life I was involved with a HB striping product for SysVr2
that had a slightly modified filesystem that 'knew' when it was
working on a striped disk. And as it know, it avoided posting I/O s
that crossed stripes.
W/
--
| / o / /_ _ email: [EMAIL PROTECTED]
|/|/ / / /( (_) Bulte Arnhem, The Netherlands
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Tue, Dec 11, 2001 at 03:34:37PM +0100, Wilko Bulte wrote: > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > > I think this is what Mike was referring to when talking about parity > > calculation. In any case, going across a stripe boundary is not a > > good idea, though of course it can't be avoided. That's one of the > > arguments for large stripes. > > In a former life I was involved with a HB striping product for SysVr2 > that had a slightly modified filesystem that 'knew' when it was > working on a striped disk. And as it know, it avoided posting I/O s > that crossed stripes. Here some real world statistics with UFS softupdates: Plex d1.p0: Size: 8736473088 bytes (8331 MB) Subdisks:3 State: up Organization: striped Stripe size: 256 kB Part of volume d1 Reads: 83546 Bytes read:258429952 (246 MB) Average read: 3093 bytes Writes: 100109 Bytes written: 818750464 (780 MB) Average write: 8178 bytes Multiblock: 279 (0%) Multistripe: 82 (0%) Subdisk 0: d1.p0.s0 state: up size 2912157696 (2777 MB) Subdisk 1: d1.p0.s1 state: up size 2912157696 (2777 MB) Subdisk 2: d1.p0.s2 state: up size 2912157696 (2777 MB) You can easily see that the number of Multistripe transactions are unnoticeable low. Here another case with 64k stripe size: Plex d7.p0: Size: 36419796992 bytes (34732 MB) Subdisks:2 State: up Organization: striped Stripe size: 64 kB Part of volume d7 Reads:934001 Bytes read: 3718752768 (3546 MB) Average read: 3981 bytes Writes: 220293 Bytes written:3702993920 (3531 MB) Average write: 16809 bytes Multiblock:50037 (4%) Multistripe: 25047 (2%) Subdisk 0: d7.p0.s0 state: up size 18209898496 (17366 MB) Subdisk 1: d7.p0.s1 state: up size 18209898496 (17366 MB) You can see that even we have an absolute extrem situation the number of multistripe transactions is still very low. But a value of 384k would be a much better value for other reasons. You may want to compare the multistripe number with the multiblock number and yes it doesn't look that good anymore, but you also see that the change from 64k to 256k get much better results, while the average transaction size is 5865 bytes for the first case and 6429 bytes for the second - not that different. Most of my plexes are concat anyway. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Hiten Pandya <[EMAIL PROTECTED]> wrote:
> i wanted to ask if there were any _plans_ to port
> JFS (Journaled File System) to FreeBSD...
As long as nobody gets the idea to import VxFS... It's dog slow
compared to UFS+softupdates. :-) Dog slow even compared to
Solaris 8 UFS+logging. Of course, i know it has other advantages,
but the journalling feature doesn't seem to be the best. Even
my notebook with its slooow (low-power) IDE drive is faster than
Solaris 8 fibre-channel disks running with VxFS. ;-)
("faster" means in terms of filesystem metadata operation, like file
creations and deletions, since that's the area you normally want to
employ journalling or softupdates for.)
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
On Tue, Dec 11, 2001 at 10:27:54PM +0100, Joerg Wunsch wrote: > Hiten Pandya <[EMAIL PROTECTED]> wrote: > > > i wanted to ask if there were any _plans_ to port > > JFS (Journaled File System) to FreeBSD... > > As long as nobody gets the idea to import VxFS... It's dog slow > compared to UFS+softupdates. :-) Dog slow even compared to [This is directed at Joerg, but I deleted the original email. URL is wrapped with a \.] http://www.usenix.org/publications/library/proceedings/usenix2000/general\ /full_papers/seltzer/seltzer_html/index.html -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Invitation for seminar. Ïðèãëàøåíèå íà ñåìèíàð
Ïðåäñòàâèòåëüñòâî Êîìïàíèè Capital Standard Corporation ïðèãëàøàåò Âàñ ïðèíÿòü ó÷àñòèå â îäíîäíåâíûõ êîíñóëüòàöèîííûõ ñåìèíàðàõ-ïðàêòèêóìàõ äëÿ ýôôåêòèâíîãî è áûñòðîãî ïîâûøåíèÿ êâàëèôèêàöèè ñîòðóäíèêîâ Âàøåé êîìïàíèè Îäíîäíåâíûé êîíñóëüòàöèîííûé ñåìèíàð-ïðàêòèêóì «Áèðæåâàÿ òîðãîâëÿ íà ìåæäóíàðîäíûõ ôèíàíñîâûõ ðûíêàõ. Ïðàêòè÷åñêèå àñïåêòû» Äàòà ïðîâåäåíèÿ: 19 äåêàáðÿ 2001 ãîäà Âðåìÿ ïðîâåäåíèÿ ñåìèíàðà: 9.30-17.30 Ìåñòî ïðîâåäåíèÿ: Èíñòèòóò ìåæäóíàðîäíûõ îòíîøåíèé  ïðîãðàììå ñåìèíàðà: 1. Ñïåêóëÿöèè - êàê ñïîñîá ïðèóìíîæåíèÿ êàïèòàëà: - ×àñòíûå èíâåñòîðû - Êîðïîðàòèâíûå è äðóãèå ó÷àñòíèêè ðûíêà - Ñóììà, äîñòàòî÷íàÿ äëÿ ðàáîòû 2. Èíñòðóìåíòû ìèðîâûõ òîâàðíûõ è ôèíàíñîâûõ ðûíêîâ: - FOREX - ìåæäóíàðîäíûé ðûíîê îáìåíà âàëþò - Ôüþ÷åðñíûå è îïöèîííûå êîíòðàêòû 3. Òåõíîëîãèÿ è ìåõàíèçì áèðæåâûõ è âíåáèðæåâûõ îïåðàöèé: - Çàêîíîäàòåëüíàÿ áàçà, ïðàâèëà è ïðàêòèêà àìåðèêàíñêîé ìîäåëè òîðãîâëè - Âàëþòíûé ðûíîê «spot» - Áèðæåâûå òîðãîâûå ñèñòåìû - Êîìïüþòåðíûå òîðãîâûå ñèñòåìû - Èíôîðìàöèîííûå ñèñòåìû è êîìïüþòåðíûå òåõíîëîãèè ïî îáåñïå÷åíèþ äèëèíãîâûõ îïåðàöèé 4. Êàê «äîòÿíóòüñÿ» äî ðûíêà: - Áðîêåðñêàÿ êîìïàíèÿ - Ïðèíöèïàë (ìàðêåò-ìåéêåð) - Òîðãîâûé ñ÷¸ò - Ìàðæà - Êðåäèòíîå ïëå÷î - Ñîâåðøåíèå ñäåëêè - Ïëþñû è ìèíóñû "èíòåðíåò-òîðãîâëè" - Ïðèáûëüíîñòü îïåðàöèé 5. Ïðîãíîçèðîâàíèå ðûíî÷íûõ òåíäåíöèé: - Òåõíè÷åñêèé àíàëèç - Ôóíäàìåíòàëüíûé àíàëèç - Ïðîôåññèîíàëüíûå êîìïüþòåðíûå ñèñòåìû è ïðîãðàììíîå îáåñïå÷åíèå, èñïîëüçóåìîå â ðàáîòå äèëåðîâ Ñòîèìîñòü ó÷àñòèÿ â ñåìèíàðå: 440 ãðèâåí Äëÿ âòîðîãî è òðåòüåãî ó÷àñòíèêà îò îäíîé êîìïàíèè ñêèäêà 10%.  ñòîèìîñòü âêëþ÷åíû: îáó÷åíèå è êîíñóëüòàöèè íà ñåìèíàðå, îáåä, êîôå-áðåéêè. Ýêñêëþçèâíûé àëüáîì ìàòåðèàëîâ «Áèðæåâàÿ òîðãîâëÿ íà ìåæäóíàðîäíûõ ôèíàíñîâûõ ðûíêàõ. Ïðàêòè÷åñêèå àñïåêòû», ïîäãîòîâëåííîãî ýêñïåðòàìè ñïåöèàëüíî äëÿ ó÷àñòíèêîâ ñ ó÷¸òîì âñåõ ïîñëåäíèõ èçìåíåíèé è äîïîëíåíèé. Îäíîäíåâíûé êîíñóëüòàöèîííûé ñåìèíàð-ïðàêòèêóì: «Òàìîæåííîå ðåãóëèðîâàíèå âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè» Äàòà ïðîâåäåíèÿ: 21 äåêàáðÿ 2001 ãîäà Âðåìÿ ïðîâåäåíèÿ ñåìèíàðà: 9.30-17.30 Ìåñòî ïðîâåäåíèÿ: Êîíôåðåíö-çàë ãîñòèíèöû «Ñàíêò-Ïåòåðáóðã» Â ïðîãðàììå ñåìèíàðà: Îñîáåííîñòè òàìîæåííîãî çàêîíîäàòåëüñòâà â ñôåðå âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè. Çàêîí Óêðàèíû «Î Òàìîæåííîì òàðèôå Óêðàèíû» îò 5.04.2001 ¹ 2371-²²². Èçìåíåíèÿ è äîïîëíåíèÿ â Çàêîí Óêðàèíû ïî ñîñòîÿíèþ íà 1.12.01. Óêðàèíñêàÿ òîâàðíàÿ íîìåíêëàòóðà âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè. Îñîáåííîñòè òàìîæåííîãî îôîðìëåíèÿ â ðàìêàõ ñîãëàøåíèé î ñâîáîäíîé òîðãîâëå. Ïåðñïåêòèâà ðàçâèòèÿ çîíû ñâîáîäíîé òîðãîâëè. Íîâûå ïðàâèëà ñòðàíû ïðîèñõîæäåíèÿ òîâàðîâ. Ïîðÿäîê ïðèìåíåíèÿ ñåðòèôèêàòîâ CT-1, EUR 1,2. Âîïðîñû êëàññèôèêàöèè òîâàðîâ. Îáçîð íîðìàòèâíûõ äîêóìåíòîâ ÃÒÑÓ ïî âîïðîñàì òàðèôíîãî ðåãóëèðîâàíèÿ ïî ñîñòîÿíèþ íà 1.12.01. Îñîáåííîñòè çàïîëíåíèÿ ÃÒÄ ïðè ðàçëè÷íûõ òàìîæåííûõ ðåæèìàõ. Ëèçèíãîâûå êîíòðàêòû, âðåìåííûé ââîç òîâàðà. Îôîðìëåíèå ÃÒÄ ïî âíåøíåýêîíîìè÷åñêèì äîãîâîðàì ñ ó÷àñòèåì áîëåå äâóõ ñòîðîí. Êðèòåðèè îïðåäåëåíèÿ òàìîæåííûìè îðãàíàìè Óêðàèíû «ãðóïï ðèñêà» (âíåøíåýêîíîìè÷åñêèå îïåðàöèè, êîòîðûå òðåáóþò äåòàëüíîé ïðîâåðêè íà çàêîííîñòü ñäåëêè). Óñòàíîâëåíèå ôàêòîâ òàìîæåííûõ ïðàâîíàðóøåíèé, êëàññèôèêàöèÿ è ïðîöåññóàëüíîå îôîðìëåíèå ôàêòîâ ïðàâîíàðóøåíèé, ñàíêöèè, ïðåäóñìîòðåííûå çàêîíîäàòåëüñòâîì, ïîñëåäñòâèÿ âîçìîæíûå äëÿ ñóáúåêòîâ ÂÝÄ. Ïðàâîâûå îñíîâû äëÿ îñóùåñòâëåíèÿ ìåæäóíàðîäíîé àäìèíèñòðàòèâíîé ïîìîùè â òàìîæåííûõ çîíàõ (ó÷àñòèå Óêðàèíû â ìåæäóíàðîäíûõ êîíâåíöèÿõ ïî òàìîæåííûì âîïðîñàì, äâóõ- è ìíîãîñòîðîííèå ìåæãîñóäàðñòâåííûå äîãîâîðà). Ïîðÿäîê ðåàëèçàöèè êîíâåíöèé, ñîãëàøåíèé, î âçàèìíîé àäìèíèñòðàòèâíîé ïîìîùè â òàìîæåííûõ âîïðîñàõ. Ñòîèìîñòü ó÷àñòèÿ â ñåìèíàðå 570 ãðèâåí Äëÿ âòîðîãî è òðåòüåãî ó÷àñòíèêà îò îäíîé ôèðìû ñêèäêà 10%.  ñòîèìîñòü âêëþ÷åíû: îáó÷åíèå è êîíñóëüòàöèè íà ñåìèíàðå, îáåä, êîôå-áðåéêè. Ýêñêëþçèâíûé àëüáîì ìàòåðèàëîâ «Òàìîæåííîå ðåãóëèðîâàíèå âíåøíåýêîíîìè÷åñêîé äåÿòåëüíîñòè», ïîäãîòîâëåííîãî ýêñïåðòàìè ñïåöèàëüíî äëÿ ó÷àñòíèêîâ ñ ó÷¸òîì âñåõ ïîñëåäíèõ èçìåíåíèé è äîïîëíåíèé Íàøà êîìïàíèÿ ïðåäëàãàåò òàêóþ óñëóãó êàê ïðîâåäåíèå èíäèâèäóàëüíûõ êîíñóëüòàöèîííûõ ñåìèíàðîâ ïî âûáðàííîé Âàìè òåìàòèêå ó Âàñ â îôèñå. Äëÿ ó÷àñòèÿ â ñåìèíàðå íåîáõîäèìî çàðåãèñòðèðîâàòüñÿ ïî íàøèì òåëåôîíàì è ïîäòâåðäèòü ñâîå ó÷àñòèå îïëàòîé (044) 494 46 58, E-mail: [EMAIL PROTECTED] Ìû ïðèíîñèì ñâîè èçâèíåíèÿ, åñëè ïîäîáíàÿ ðàññûëêà Âàì íå èíòåðåñíà. Óäàëèòü ñâîé àäðåñ èç ñïèñêà ïîäïèñ÷èêîâ Âû ìîæåòå, îòîñëàâ ïèñüìî ïî àäðåñó [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote:
> On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote:
>> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote:
>>>
> performance without it - for reading OR writing. It doesn't matter
> so much for RAID{1,10}, but it matters a whole lot for something like
> RAID-5 where the difference between a spindle-synced read or write
> and a non-spindle-synched read or write can be upwards of 35%.
If you have RAID5 with I/O sizes that result in full-stripe operations.
>>>
>>> Well, 'more then one disk' operations anyway, for random-I/O. Caching
>>> takes care of sequential I/O reasonably well but random-I/O goes down
>>> the drain for writes if you aren't spindle synced, no matter what
>>> the stripe size,
>>
>> Can you explain this? I don't see it. In FreeBSD, just about all I/O
>> goes to buffer cache.
>>
>>> and will go down the drain for reads if you cross a stripe -
>>> something that is quite common I think.
>>
>> I think this is what Mike was referring to when talking about parity
>> calculation. In any case, going across a stripe boundary is not a
>> good idea, though of course it can't be avoided. That's one of the
>> arguments for large stripes.
>
> In a former life I was involved with a HB striping product for SysVr2
> that had a slightly modified filesystem that 'knew' when it was
> working on a striped disk. And as it know, it avoided posting I/O s
> that crossed stripes.
So what did it do with user requests which crossed stripes?
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
On Tue, Dec 11, 2001 at 02:07:40PM -0800, Steve Kargl wrote: > On Tue, Dec 11, 2001 at 10:27:54PM +0100, Joerg Wunsch wrote: > > Hiten Pandya <[EMAIL PROTECTED]> wrote: > > > > > i wanted to ask if there were any _plans_ to port > > > JFS (Journaled File System) to FreeBSD... > > > > As long as nobody gets the idea to import VxFS... It's dog slow > > compared to UFS+softupdates. :-) Dog slow even compared to > > [This is directed at Joerg, but I deleted the original email. ^ not > URL is wrapped with a \.] > > http://www.usenix.org/publications/library/proceedings/usenix2000/general\ > /full_papers/seltzer/seltzer_html/index.html > > -- > Steve > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Wed, Dec 12, 2001 at 09:00:34AM +1030, Greg Lehey wrote: > On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote: > > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > >> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > >>> .. > >>> and will go down the drain for reads if you cross a stripe - > >>> something that is quite common I think. > >> > >> I think this is what Mike was referring to when talking about parity > >> calculation. In any case, going across a stripe boundary is not a > >> good idea, though of course it can't be avoided. That's one of the > >> arguments for large stripes. > > > > In a former life I was involved with a HB striping product for SysVr2 > > that had a slightly modified filesystem that 'knew' when it was > > working on a striped disk. And as it know, it avoided posting I/O s > > that crossed stripes. > > So what did it do with user requests which crossed stripes? Memory is dim, but I think the fs code created a second i/o to the driver layer. So the fs never sent out an i/o that the driver layer had to break up. In case of a pre-fetch while reading I think the f/s would just pre-fetch until the stripe border and not bother sending out a second i/o down. In the end all of this benchmarked quite favorably. Note that this was 386/486 era, with the classic SysV filesystem. -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
noise in audio
Hi, not sure quite how to do a bug report on this, and didn't see any bug reports that matched, so I thought I'd throw it to the list to see... Audio output on my compile of current has noise in the audio stream, it's usually very regular... an mp3 pops at a little more than 1hz, a wav is too fast to guess on, almost a buzz. 'sync' and other utils that force disk io make a nasty beep noise, I'm guessing the popping is a very short occurance of that. Compiling puts some ugly noises out through it. 4.4 didn't do it, and I'm dual booting with linux and that doesn't do it, so I don't believe it's strictly hardware. I've posted my kernel config, uname, and dmesg at http://www.smluc.org/~erik/fbsd/ I'm willing to work on this, but I don't want to duplicate effort or spend too long fighting it if it's a stupid config mistake or something :) -Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hi,All
Hi,All: I love FreeBSD! But.. Can it support CD-RW disc and Simplie Chinese Filename? A lot of files in CD-ROM that have Chinese name, how can i open it under FreeBSD? Oh...Oh Best Regard. _ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
On Tuesday, 11 December 2001 at 1:08:23 -0800, Terry Lambert wrote: > Greg Lehey wrote: >>> FS porting to FreeBSD is actually pretty trivial(*), though some >>> transactioning changes to the FreeBSD VFS layer consumers (the >>> system calls and NFS server code) would be necessary to make >>> the journal roll-back function correctly, following a failure. >>> >>> (*) Trivial: meaning grunt work is required; not necessarily an >>> indicator of the amount of work, only the intellectual effort >>> required for the job >> >> Considering that the current UFS implementation didn't need to be >> ported, and people are still working on the details, I think that this >> is a highly misleading statement. > > The current UFS has a number of issues which make it non-trivial; > it was, in effect, a port; here is the short list: > > > > Live code always has issues, particularly if you are trying to > pound a round peg into a square hole (hence Kirk taking up the > task of a redesign). Of course. But you're missing the point: ufs is *not* a port, it has been with BSD since the beginning. There is a similar list of items for JFS which would need to be addressed, with the additional issue of the fact that it was not designed for FreeBSD. > I think that everyone saying "Ut oh! SCARY!" gives people the wrong > idea, and scares off potential contributors in these areas. I'm not saying that. I'm saying that it's non-trivial, which I suppose is what you mean when you say "where are the patches?". As I said, I'm quite happy to help people port JFS2 to FreeBSD. On Tuesday, 11 December 2001 at 2:26:45 -0800, Hiten Pandya wrote: >> [... Hiten want's to GPL'ify FreeBSD ...] > > hi, > first of all, i would like to clear of some point which have been > taken wrongly. > > o My Intentions were never to GPL'ify FreeBSD :-) Agreed, I don't think anybody thought that. > o The reason i started this discussion was because >i think JFS/JFS2 would be a nice addition to >FreeBSD like the rest of the other filesystems. > > o The JFS does _not_ have to be root, and even if >people were to download it because it is GPL'ed, >the size of the filesystem is only around 1.0MB If we port JFS2, it will be relatively trivial to have it as the root file system too. > o It is hard to Port AIX or OS/2 based code, but we >have to agree that, BSD Users were meant to take >that kind of challenges, have taken before It's probably easier to port AIX based code than OS/2 or Linux based code. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Greg Lehey wrote: > Of course. But you're missing the point: ufs is *not* a port, it has > been with BSD since the beginning. There is a similar list of items > for JFS which would need to be addressed, with the additional issue of > the fact that it was not designed for FreeBSD. I maintain that the FreeBSD UFS *is* a port of the Heidemann implementation from the FICUS project, which had to be done because certain files were claimed to be "contaminated" with USL IP, and were removed as part of the USL/UCB settlement (6 key files from 5 subsystems, which they thought we couldn't rewrite from scratch in time to be a competitive threat). I also maintain that the most difficult thing is getting the list of items, and, with the information from the UFS work in hand, the JFS specific items not on that list are trivial (there are exactly two items, in fact: log roll forward/backward, and transaction abort). > > I think that everyone saying "Ut oh! SCARY!" gives people the wrong > > idea, and scares off potential contributors in these areas. > > I'm not saying that. I'm saying that it's non-trivial, which I > suppose is what you mean when you say "where are the patches?". As I > said, I'm quite happy to help people port JFS2 to FreeBSD. I ported the entire GFS user space tools set, sans two, to FreeBSD in about 2 hours. If FreeBSD had the necessary hardware drivers for shared disks, I would have finished the two that I didn't do, and then I would have gone to Frys, bought the necessary controllers, disk, and two scratch boxes, and finished porting the whole damn thing. I think I could have it all up and running in about 4 weeks, assuming the Linux implementation actually works for more than one machine, and my test machines were configured dual boot for Linux/FreeBSD. Unlike IBM, the GFS people have indicated a willingness to bend on the license issue. When I say "trivial", I mean "trivial", as the term is used in physics or mathematics: a well understood operation that can be performed rote, and does not require significant original thinking to perform. When I say "where are the patches?" I mean "that's an incredibly stupid idea, given the license, and you aren't going to get me to do that work without paying me, so you might as well send patches -- do the work yourself -- because you are going to have a hell of a time getting buy-in from anyone clued enough to do the work for you". > If we port JFS2, it will be relatively trivial to have it as the root > file system too. Only, you will never be able to build a firewall, router, or other product that ships with it statically linked into the kernel, since that would violate the terms of the GPL (additional restrictions, and linked code not being GPL'ed). What good is the damn thing, if the only people who can use it are big site admins who build their own kernels, and never expect to sell their company to anyone (or are prepared to recompile all the kernels on all their machines, should the company ever sell, since they can't transfer ownership of a FreeBSD kernel with GPL'ed code in it directly, without violating the license)? RMS has indicated a willingness to sue people distributing bipartite distributions, where the linking is delayed until installation to work around the letter of the GPL. Given his religious convictions, I can't see him *not*. Factor that into your decision. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dhclient busted for -current?
In message <[EMAIL PROTECTED]> "Pierre Y. Dampure" writes: : Are you asking for specific options (my dhclient.conf is empty)? are you using a :reservation? I'm 100% sure it worked before the upgrade. :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))
On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote:
> On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote:
>> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote:
>>>
> performance without it - for reading OR writing. It doesn't matter
> so much for RAID{1,10}, but it matters a whole lot for something like
> RAID-5 where the difference between a spindle-synced read or write
> and a non-spindle-synched read or write can be upwards of 35%.
If you have RAID5 with I/O sizes that result in full-stripe operations.
>>>
>>> Well, 'more then one disk' operations anyway, for random-I/O. Caching
>>> takes care of sequential I/O reasonably well but random-I/O goes down
>>> the drain for writes if you aren't spindle synced, no matter what
>>> the stripe size,
>>
>> Can you explain this? I don't see it. In FreeBSD, just about all I/O
>> goes to buffer cache.
>
> After waiting for the drives and not for vinum parity blocks.
>
>>> and will go down the drain for reads if you cross a stripe -
>>> something that is quite common I think.
>>
>> I think this is what Mike was referring to when talking about parity
>> calculation. In any case, going across a stripe boundary is not a
>> good idea, though of course it can't be avoided. That's one of the
>> arguments for large stripes.
>
> striped:
> If you have 512byte stripes and have 2 disks.
> You access 64k which is put into 2 32k transactions onto the disk.
Only if your software optimizes the transfers. There are reasons why
it should not. Without optimization, you get 128 individual
transfers.
> The wait time for the complete transaction is the worst of both,
> which is more than the average of a single disk.
Agreed.
> With spindle syncronisation the access time for both disks are
> beleaved to be identic and you get the same as with a single disk.
Correct.
> Linear speed could be about twice the speed of a single drive. But
> this is more theoretic today than real. The average transaction
> size per disk decreases with growing number of spindles and you get
> more transaction overhead. Also the voice coil technology used in
> drives since many years add a random amount of time to the access
> time, which invalidates some of the spindle sync potential. Plus it
> may break some benefits of precaching mechanisms in drives. I'm
> almost shure there is no real performance gain with modern drives.
The real problem with this scenario is that you're missing a couple of
points:
1. Typically it's not the latency that matters. If you have to wait
a few ms longer, that's not important. What's interesting is the
case of a heavily loaded system, where the throughput is much more
important than the latency.
2. Throughput is the data transferred per unit time. There's active
transfer time, nowadays in the order of 500 µs, and positioning
time, in the order of 6 ms. Clearly the fewer positioning
operations, the better. This means that you should want to put
most transfers on a single spindle, not a single stripe. To do
this, you need big stripes.
> raid5:
> For a write you have two read transactions and two writes.
This is the way Vinum does it. There are other possibilities:
1. Always do full-stripe writes. Then you don't need to read the old
contents.
2. Cache the parity blocks. This is an optimization which I think
would be very valuable, but which Vinum doesn't currently perform.
> There are easier things to raise performance.
> Ever wondered why people claim vinums raid5 writes are slow?
> The answer is astonishing simple:
> Vinum does striped based locking, while the ufs tries to lay out data
> mostly ascending sectors.
> What happens here is that the first write has to wait for two reads
> and two writes.
> If we have an ascending write it has to wait for the first write to
> finish, because the stripe is still locked.
> The first is unlocked after both physical writes are on disk.
> Now we start our two reads which are (thanks to drives precache)
> most likely in the drives cache - than we write.
>
> The problem here is that physical writes gets serialized and the drive
> has to wait a complete rotation between each.
Not if the data is in the drive cache.
> If we had a fine grained locking which only locks the accessed sectors
> in the parity we would be able to have more than a single ascending
> write transaction onto a single drive.
Hmm. This is something I hadn't thought about. Note that sequential
writes to a RAID-5 volume don't go to sequential addresses on the
spindles; they will work up to the end of the stripe on one spindle,
then start on the next spindle at the start of the stripe. You can do
that as long as the address ranges in the parity block don't overlap,
but the larger the stripe, the greater the likelihood of this would
be. This might also explain the following observed behav
Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Tuesday, 11 December 2001 at 23:41:51 +0100, Wilko Bulte wrote: > On Wed, Dec 12, 2001 at 09:00:34AM +1030, Greg Lehey wrote: >> On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote: >>> On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > > > .. > > and will go down the drain for reads if you cross a stripe - > something that is quite common I think. I think this is what Mike was referring to when talking about parity calculation. In any case, going across a stripe boundary is not a good idea, though of course it can't be avoided. That's one of the arguments for large stripes. >>> >>> In a former life I was involved with a HB striping product for SysVr2 >>> that had a slightly modified filesystem that 'knew' when it was >>> working on a striped disk. And as it know, it avoided posting I/O s >>> that crossed stripes. >> >> So what did it do with user requests which crossed stripes? > > Memory is dim, but I think the fs code created a second i/o to the > driver layer. So the fs never sent out an i/o that the driver layer had > to break up. That's what Vinum does. > In case of a pre-fetch while reading I think the f/s would just > pre-fetch until the stripe border and not bother sending out a > second i/o down. Yes, that's reasonable. > In the end all of this benchmarked quite favorably. Note that this > was 386/486 era, with the classic SysV filesystem. I don't think that UFS would behave that differently, just faster :-) Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
I think I would rather see people tweaking the heck out of the existing UFS filesystem and implementing new ways of getting it to go faster. Implementing a whole new filesystem would probably take a lot of work, and the performance wouldn't be much better anyways. IMHO, people interested in making a filesystem faster should stick with UFS. FreeBSD should not do what Linux does, which is make a whole bunch of different filesystems that all suck in a different way. This is an opinion and should be taken as such, not an insult to those that like the whole JFS idea. -Craig _ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
On 06-Dec-01 Bruce Evans wrote: > That gives a hint about where to look for the clobbering conventions. From > gcc/config/i386/i386.c: > > ! /* Set the cc_status for the results of an insn whose pattern is EXP. > !On the 80386, we assume that only test and compare insns, as well > !as SI, HI, & DI mode ADD, SUB, NEG, AND, IOR, XOR, BSF, ASHIFT, > !ASHIFTRT, and LSHIFTRT instructions set the condition codes usefully. > !Also, we assume that jumps, moves and sCOND don't affect the condition > !codes. All else clobbers the condition codes, by assumption. > > ! > !We assume that ALL integer add, minus, etc. instructions effect the > !condition codes. This MUST be consistent with i386.md. > ! > !We don't record any float test or compare - the redundant test & > !compare check in final.c does not handle stack-like regs correctly. */ > ! > ! void > ! notice_update_cc (exp) > ! rtx exp; > > Application asms are apparently in the "All else" set. Ok, I've axed all the "cc" clobbers from the patch now. Any objections to it now? It's still at ~jhb/patches/i386_asm.patch. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
On Tuesday, 11 December 2001 at 19:42:30 -0800, Terry Lambert wrote: > Greg Lehey wrote: >> Of course. But you're missing the point: ufs is *not* a port, it has >> been with BSD since the beginning. There is a similar list of items >> for JFS which would need to be addressed, with the additional issue of >> the fact that it was not designed for FreeBSD. > > I maintain that the FreeBSD UFS *is* a port of the Heidemann > implementation from the FICUS project, which had to be done because > certain files were claimed to be "contaminated" with USL IP, and > were removed as part of the USL/UCB settlement (6 key files from 5 > subsystems, which they thought we couldn't rewrite from scratch in > time to be a competitive threat). Which files? Did they require adapting to a different environment? > I also maintain that the most difficult thing is getting the list of > items, and, with the information from the UFS work in hand, the JFS > specific items not on that list are trivial (there are exactly two > items, in fact: log roll forward/backward, and transaction abort). I'd expect these to be the easiest parts, since they don't have too much to do with the rest of the system. One of the issues with Linux is that the interface to the rest of the system, and I don't expect these parts to have much interfacing to do. >>> I think that everyone saying "Ut oh! SCARY!" gives people the wrong >>> idea, and scares off potential contributors in these areas. >> >> I'm not saying that. I'm saying that it's non-trivial, which I >> suppose is what you mean when you say "where are the patches?". As I >> said, I'm quite happy to help people port JFS2 to FreeBSD. > > I ported the entire GFS user space tools set, sans two, to FreeBSD in > about 2 hours. I expect the user space tools for JFS2 to be pretty straightforward too. >> If we port JFS2, it will be relatively trivial to have it as the root >> file system too. > > Only, you will never be able to build a firewall, router, or other > product that ships with it statically linked into the kernel, since > that would violate the terms of the GPL (additional restrictions, > and linked code not being GPL'ed). Fine, so we load the module. What's your point? > What good is the damn thing, if the only people who can use it are > ... Well, I suppose it'll still be good for them. Maybe. > RMS has indicated a willingness to sue people distributing bipartite > distributions, where the linking is delayed until installation to > work around the letter of the GPL. Given his religious convictions, > I can't see him *not*. Factor that into your decision. You want me personally to get him to agree that loading modules at boot time does not violate the GPL? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NCP Broken ?
On Mon, 10 Dec 2001, Kaltashkin Eugene wrote: > On Fri, 7 Dec 2001 10:55:03 -0800 (PST) > Julian Elischer <[EMAIL PROTECTED]> wrote: > > JE: yes ncp and nwfs are broken in -current > > Hm, and when this be work ? when someone who understands the protocol can get time to retrofit teh KSE changes into it.. > > > -- > Best Regards > Kaltashkin Eugene > ZHECKA-RIPN > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
