Re: CVS commit: src/sys
t...@rek.tjls.com wrote: > On Wed, Mar 25, 2009 at 11:15:16PM +0900, Izumi Tsutsui wrote: > > t...@rek.tjls.com wrote: > > > > > What was added to libkern is much simpler than what's in libz (not just > > > because the libz sources are stylistically gross). It's not only meant > > > for use by libz. > > > > Even if so, it should be handled by .PATH.c: in libkern/Makefile.libkern > > to pull crc32.c, IMO. > > I disagree. For example, the unmodified crc32.c in libkern does byte > order checking at runtime, which is just pointless in the kernel. Hm, then I was confused because the log message said "from zlib to libkern." > The > libz source is so dirty, if we have to clean it up at all for in-kernel > use, better, I think, to just extract the useful part of that file and > maintain it ourselves. BTW, can it be shared with userland libz etc? --- Izumi Tsutsui
Re: CVS commit: src/sys
On Wed, Mar 25, 2009 at 11:15:16PM +0900, Izumi Tsutsui wrote: > t...@rek.tjls.com wrote: > > > What was added to libkern is much simpler than what's in libz (not just > > because the libz sources are stylistically gross). It's not only meant > > for use by libz. > > Even if so, it should be handled by .PATH.c: in libkern/Makefile.libkern > to pull crc32.c, IMO. I disagree. For example, the unmodified crc32.c in libkern does byte order checking at runtime, which is just pointless in the kernel. The libz source is so dirty, if we have to clean it up at all for in-kernel use, better, I think, to just extract the useful part of that file and maintain it ourselves. It is my intent to add a _much_ smaller crc32 function for use by STANDALONE so that even libz built into the bootblocks doesn't use the code from common/dist/libz. Thor
Re: CVS commit: src/sys
t...@rek.tjls.com wrote: > What was added to libkern is much simpler than what's in libz (not just > because the libz sources are stylistically gross). It's not only meant > for use by libz. Even if so, it should be handled by .PATH.c: in libkern/Makefile.libkern to pull crc32.c, IMO. --- Izumi Tsutsui
Re: CVS commit: src/sys
On Wed, Mar 25, 2009 at 06:14:13PM +0900, Izumi Tsutsui wrote: > dar...@netbsd.org wrote: > > > Added Files: > > src/sys/lib/libkern: crc32.c crc32.h > : > > Adds the fast version of crc32 from zlib to libkern. This should be > > generally > > useful and provide a place to start normalizing the various crc32 routines > > in the kernel. The crc32 routine is used in this patch to support GZIP. > > Isn't it better to simply build and link libz > rather than having a dumb copies in libkern? What was added to libkern is much simpler than what's in libz (not just because the libz sources are stylistically gross). It's not only meant for use by libz. Thor
Re: CVS commit: src/sys
Hi! From: Darran Hunt Date: Wed, 25 Mar 2009 01:26:14 + > Module Name: src > Committed By: darran > Date: Wed Mar 25 01:26:13 UTC 2009 > > Modified Files: > src/sys/lib/libkern: Makefile.libkern libkern.h > src/sys/lib/libkern/arch/i386: Makefile.inc > src/sys/net: zlib.h > src/sys/opencrypto: crypto.c cryptodev.c cryptodev.h cryptosoft.c > cryptosoft.h cryptosoft_xform.c deflate.c deflate.h > files.opencrypto xform.c xform.h > Added Files: > src/sys/lib/libkern: crc32.c crc32.h > src/sys/opencrypto: ocryptodev.c ocryptodev.h > > Log Message: > Fixes PR kern/41069 and PR kern/41070. > > Extends the Opencrypto API to allow the destination buffer size to be > specified when its not the same size as the input buffer (i.e. for > operations like compress and decompress). > The crypto_op and crypt_n_op structures gain a u_int dst_len field. > The session_op structure gains a comp_alg field to specify a compression > algorithm. > Moved four ioctls to new ids; CIOCGSESSION, CIOCNGSESSION, CIOCCRYPT, > and CIOCNCRYPTM. > Added four backward compatible ioctls; OCIOCGSESSION, OCIOCNGSESSION, > OCIOCCRYPT, and OCIOCNCRYPTM. > > Backward compatibility is maintained in ocryptodev.h and ocryptodev.c which > implement the original ioctls and set dst_len and comp_alg to 0. > > Adds user-space access to compression features. > > Adds software gzip support (CRYPTO_GZIP_COMP). > > Adds the fast version of crc32 from zlib to libkern. This should be generally > useful and provide a place to start normalizing the various crc32 routines > in the kernel. The crc32 routine is used in this patch to support GZIP. > > With input and support from t...@netbsd.org. I look the warning message 'cast from pointer to integer of different size' on my amd64 when rebuilding the kernel after this change perhaps. # compile kern/crc32.o cc -mcmodel=kernel -mno-red-zone -ffreestanding -fno-zero-initialized-in-bss -O2 -fno-omit-frame-pointer -std=gnu99 -fno-strict-aliasing -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-sign-compare -Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter -Werror -I../../../../../../lib/libkern/arch/x86_64 -Damd64 -Dx86_64 -I../../. -I../../../../../../../common/include -I../../../../../../arch -I../../../../../.. -nostdinc -DPCMCIACISDEBUG -DRBUS_IO_BASE="0xb000" -DRBUS_IO_SIZE="0x3000" -DRBUS_MIN_START="0xf8a0" -DMAXUSERS=64 -D_KERNEL -D_KERNEL_OPT -I../../../../../../lib/libkern/../../../common/lib/libc/quad -I../../../../../../lib/libkern/../../../common/lib/libc/string -I../../../../../../lib/libkern/../../../common/lib/libc/arch/x86_64/string -I../../../../../../external/isc/atheros_hal/dist -I../../../../../../external/isc/a! theros_hal/ic -I../../../../../../dev/drm -I../../../../../../../common/include -I../../../../../../dev/pci/drm -I../../../../../../lib/libkern/../../../common/lib/libc/quad -I../../../../../../lib/libkern/../../../common/lib/libc/string -I../../../../../../lib/libkern/../../../common/lib/libc/arch/x86_64/string -I../../../../../../lib/libkern/../../../common/include-c ../../../../../../lib/libkern/crc32.c -o crc32.o cc1: warnings being treated as errors ../../../../../../lib/libkern/crc32.c: In function 'crc32': ../../../../../../lib/libkern/crc32.c:55: warning: cast from pointer to integer of different size *** Error code 1 Please fix. Thanks, -- kiyohara
Re: CVS commit: src/sys
dar...@netbsd.org wrote: > Added Files: > src/sys/lib/libkern: crc32.c crc32.h : > Adds the fast version of crc32 from zlib to libkern. This should be generally > useful and provide a place to start normalizing the various crc32 routines > in the kernel. The crc32 routine is used in this patch to support GZIP. Isn't it better to simply build and link libz rather than having a dumb copies in libkern? --- Izumi Tsutsui
Re: CVS commit: src/lib/libc/sys
On Wed, Mar 25, 2009 at 08:58:18AM +, Andrew Doran wrote: > > Log Message: > > Update the note about sync returning before buffers are written: it is a > > piece of historical behavior, not a current bug. Also, while here, add a > > bit about disk write-back caches and point to dkctl/scsictl. > > Bump date. (first time since 1993!) > > Thanks, however: > > +.Sh CAUTIONS > +Many modern disks contain write-back caches. > +In theory > +.Fn sync > +flushes these. > > This is not true, unless you are using logging (or zfs!). It should be true; why is it not? Does this need to be moved under BUGS? > +In practice there are many possible ways for this mechanism to go > +astray. > +It is prudent (where possible) to allow a few seconds after syncing > +for everything to settle before e.g. turning off the power. > +.Pp > +It may also be desirable to use > +.Xr dkctl 8 > +or > +.Xr scsictl 8 > +to disable the write-back cache entirely. > > This is wishy washy. It gives the sense that we know there is a problem, but > simply couldn't be arsed fixing it. What do you want to convey? Should we have a list of filesystems and whether they work properly? Crossreferences to mount_foo(8) for all foo? Or should it just contain Kirk's advice, that is, people who care about their data shouhld always disable the write-back cache? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/sys
On Wed, Mar 25, 2009 at 05:32:52AM +, David A. Holland wrote: > Log Message: > Update the note about sync returning before buffers are written: it is a > piece of historical behavior, not a current bug. Also, while here, add a > bit about disk write-back caches and point to dkctl/scsictl. > Bump date. (first time since 1993!) Thanks, however: +.Sh CAUTIONS +Many modern disks contain write-back caches. +In theory +.Fn sync +flushes these. This is not true, unless you are using logging (or zfs!). +In practice there are many possible ways for this mechanism to go +astray. +It is prudent (where possible) to allow a few seconds after syncing +for everything to settle before e.g. turning off the power. +.Pp +It may also be desirable to use +.Xr dkctl 8 +or +.Xr scsictl 8 +to disable the write-back cache entirely. This is wishy washy. It gives the sense that we know there is a problem, but simply couldn't be arsed fixing it. What do you want to convey?
Re: CVS commit: src/lib/libc/sys
On Wed, Mar 25, 2009 at 09:44:42AM +0100, Thomas Klausner wrote: > > Oops. > > > > Good to know I can spell. Or something. > > You were spelling alright, but the ordering in SEE ALSO has section > first, name second... Failing to order small integers correctly is not exactly a *less* embarrassing mistake. Or something... anyway. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/sys
On Wed, Mar 25, 2009 at 08:08:04AM +, David Holland wrote: > On Wed, Mar 25, 2009 at 06:46:21AM +, Thomas Klausner wrote: > > Modified Files: > >src/lib/libc/sys: sync.2 > > > > Log Message: > > Sort SEE ALSO. > > Oops. > > Good to know I can spell. Or something. You were spelling alright, but the ordering in SEE ALSO has section first, name second... Thomas
