Re: 8 to 9: Kernel modularization -- did it change?
Doug Barton do...@freebsd.org wrote: loading modules through loader.conf is veeryy slooww ... Is it noticeably slower to load (say) a 6MB kernel + 2MB of modules than to load an 8MB kernel? If so, any idea why? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: devd based AUTOMOUNTER
Added a check if ntfs-3g is available, if not then mount_ntfs is used instead.
Added deleting of empty directories at ${MNTPREFIX}.
Added ${MNTPREFIX} to be set to /mnt or /media according to preference
#! /bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
MNTPREFIX=/media
LOG=/var/log/automount.log
STATE=/var/run/automount.state
DATEFMT=%Y-%m-%d %H:%M:%S
__create_mount_point() { # /* 1=DEV */
MNT=${MNTPREFIX}/$( basename ${1} )
mkdir -p ${MNT}
}
__state_lock() {
while [ -f ${STATE}.lock ]; do sleep 0.5; done
: ${STATE}.lock
}
__state_unlock() {
rm ${STATE}.lock
}
__state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */
__state_lock
grep -E ${3} ${STATE} 1 /dev/null 2 /dev/null {
__log ${1}:duplicated '${STATE}'
return 1
}
echo ${1} ${2} ${3} ${STATE}
__state_unlock
}
__state_remove() { # /* 1=MNT 2=STATE 3=LINE */
BSMNT=$( echo ${1} | sed 's/\//\\\//g' )
sed -i '' /${BSMNT}\$/d ${2}
}
__log() { # /* @=MESSAGE */
echo $( date +${DATEFMT} ) ${@} ${LOG}
}
case ${2} in
(attach)
for I in /dev/${1}*
do
case $( file -L -s ${I} | sed -E 's/label:\ \.*\//g' ) in
(*NTFS*)
dd ${I} count=1 2 /dev/null \
| strings \
| head -1 \
| grep -q NTFS {
__create_mount_point ${I}
which ntfs-3g 1 /dev/null 2 /dev/null {
ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */
} || {
mount_ntfs ${I} ${MNT}
}
__log ${I}:mount (ntfs)
}
;;
(*FAT*)
dd ${I} count=1 2 /dev/null \
| strings \
| grep -q FAT32 {
__create_mount_point ${I}
fsck_msdosfs -y ${I}
mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} ${MNT}
__log ${I}:mount (fat)
}
;;
(*ext2*)
__create_mount_point ${I}
fsck.ext2 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext2)
;;
(*ext3*)
__create_mount_point ${I}
fsck.ext3 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext3)
;;
(*ext4*)
__create_mount_point ${I}
fsck.ext4 -y ${I}
ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */
__log ${I}:mount (ext4)
;;
(*Unix\ Fast\ File*)
__create_mount_point ${I}
fsck_ufs -y ${I}
mount ${I} ${MNT}
__log ${I}:mount (ufs)
;;
(*)
case $( dd ${I} count=1 2 /dev/null | strings | head -1 ) in
(EXFAT)
__create_mount_point ${I}
mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */
__log ${I}:mount (ufs)
;;
(*) continue ;;
esac
;;
esac
__state_add ${I} $( mount | grep -m 1 ${MNT} | awk '{printf $1}' ) \
${MNT} || continue
done
;;
(detach)
MOUNT=$( mount )
__state_lock
grep ${1} ${STATE} \
| while read DEV PROVIDER MNT
do
TARGET=$( echo ${MOUNT} | grep -E ^${PROVIDER} | awk '{print
$3}' )
[ -z ${TARGET} ] {
__state_remove ${MNT} ${STATE} ${LINE}
continue
}
umount -f ${TARGET}
unset TARGET
__state_remove ${MNT} ${STATE} ${LINE}
__log ${DEV}:umount
done
__state_unlock
__log /dev/${1}:detach
find ${MNTPREFIX} -type d -empty -delete
;;
esac
Not sure if you've looked at disktype in sysutils
but it may be useful to you.
I will get look into that, thanks ;)
Neat scripts!
Matt
Thanks mate.
Regards,
vermaden
--
...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: devd based AUTOMOUNTER
On Saturday 18 February 2012 10:48:11 vermaden wrote:
Added a check if ntfs-3g is available, if not then mount_ntfs is used
instead. Added deleting of empty directories at ${MNTPREFIX}.
Added ${MNTPREFIX} to be set to /mnt or /media according to preference
#! /bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
MNTPREFIX=/media
LOG=/var/log/automount.log
STATE=/var/run/automount.state
DATEFMT=%Y-%m-%d %H:%M:%S
__create_mount_point() { # /* 1=DEV */
MNT=${MNTPREFIX}/$( basename ${1} )
mkdir -p ${MNT}
}
__state_lock() {
while [ -f ${STATE}.lock ]; do sleep 0.5; done
: ${STATE}.lock
}
__state_unlock() {
rm ${STATE}.lock
}
__state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */
__state_lock
grep -E ${3} ${STATE} 1 /dev/null 2 /dev/null {
__log ${1}:duplicated '${STATE}'
return 1
}
echo ${1} ${2} ${3} ${STATE}
__state_unlock
}
__state_remove() { # /* 1=MNT 2=STATE 3=LINE */
BSMNT=$( echo ${1} | sed 's/\//\\\//g' )
sed -i '' /${BSMNT}\$/d ${2}
}
__log() { # /* @=MESSAGE */
echo $( date +${DATEFMT} ) ${@} ${LOG}
}
case ${2} in
(attach)
for I in /dev/${1}*
do
case $( file -L -s ${I} | sed -E 's/label:\ \.*\//g' ) in
(*NTFS*)
dd ${I} count=1 2 /dev/null \
| strings \
| head -1 \
| grep -q NTFS {
__create_mount_point ${I}
which ntfs-3g 1 /dev/null 2 /dev/null {
ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */
} || {
mount_ntfs ${I} ${MNT}
}
__log ${I}:mount (ntfs)
}
;;
(*FAT*)
dd ${I} count=1 2 /dev/null \
| strings \
| grep -q FAT32 {
__create_mount_point ${I}
fsck_msdosfs -y ${I}
mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I}
${MNT} __log ${I}:mount (fat)
}
;;
(*ext2*)
__create_mount_point ${I}
fsck.ext2 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext2)
;;
(*ext3*)
__create_mount_point ${I}
fsck.ext3 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext3)
;;
(*ext4*)
__create_mount_point ${I}
fsck.ext4 -y ${I}
ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */
__log ${I}:mount (ext4)
;;
(*Unix\ Fast\ File*)
__create_mount_point ${I}
fsck_ufs -y ${I}
mount ${I} ${MNT}
__log ${I}:mount (ufs)
;;
(*)
case $( dd ${I} count=1 2 /dev/null | strings | head -1 ) in
(EXFAT)
__create_mount_point ${I}
mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */
__log ${I}:mount (ufs)
;;
(*) continue ;;
esac
;;
esac
__state_add ${I} $( mount | grep -m 1 ${MNT} | awk '{printf $1}'
) \ ${MNT} || continue
done
;;
(detach)
MOUNT=$( mount )
__state_lock
grep ${1} ${STATE} \
| while read DEV PROVIDER MNT
do
TARGET=$( echo ${MOUNT} | grep -E ^${PROVIDER} | awk '{print
$3}' ) [ -z ${TARGET} ] {
__state_remove ${MNT} ${STATE} ${LINE}
continue
}
umount -f ${TARGET}
unset TARGET
__state_remove ${MNT} ${STATE} ${LINE}
__log ${DEV}:umount
done
__state_unlock
__log /dev/${1}:detach
find ${MNTPREFIX} -type d -empty -delete
;;
esac
Not sure if you've looked at disktype in sysutils
but it may be useful to you.
Hi,
Should your script be written like an rc.d script, so that one can
enable/disable this automounting from /etc/rc.conf?
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: devd based AUTOMOUNTER
On 2012-02-18 14:09, Hans Petter Selasky wrote:
On Saturday 18 February 2012 10:48:11 vermaden wrote:
Added a check if ntfs-3g is available, if not then mount_ntfs is used
instead. Added deleting of empty directories at ${MNTPREFIX}.
Added ${MNTPREFIX} to be set to /mnt or /media according to preference
#! /bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
MNTPREFIX=/media
LOG=/var/log/automount.log
STATE=/var/run/automount.state
DATEFMT=%Y-%m-%d %H:%M:%S
__create_mount_point() { # /* 1=DEV */
MNT=${MNTPREFIX}/$( basename ${1} )
mkdir -p ${MNT}
}
__state_lock() {
while [ -f ${STATE}.lock ]; do sleep 0.5; done
: ${STATE}.lock
}
__state_unlock() {
rm ${STATE}.lock
}
__state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */
__state_lock
grep -E ${3} ${STATE} 1 /dev/null 2 /dev/null {
__log ${1}:duplicated '${STATE}'
return 1
}
echo ${1} ${2} ${3} ${STATE}
__state_unlock
}
__state_remove() { # /* 1=MNT 2=STATE 3=LINE */
BSMNT=$( echo ${1} | sed 's/\//\\\//g' )
sed -i '' /${BSMNT}\$/d ${2}
}
__log() { # /* @=MESSAGE */
echo $( date +${DATEFMT} ) ${@} ${LOG}
}
case ${2} in
(attach)
for I in /dev/${1}*
do
case $( file -L -s ${I} | sed -E 's/label:\ \.*\//g' ) in
(*NTFS*)
dd ${I} count=1 2 /dev/null \
| strings \
| head -1 \
| grep -q NTFS {
__create_mount_point ${I}
which ntfs-3g 1 /dev/null 2 /dev/null {
ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */
} || {
mount_ntfs ${I} ${MNT}
}
__log ${I}:mount (ntfs)
}
;;
(*FAT*)
dd ${I} count=1 2 /dev/null \
| strings \
| grep -q FAT32 {
__create_mount_point ${I}
fsck_msdosfs -y ${I}
mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I}
${MNT} __log ${I}:mount (fat)
}
;;
(*ext2*)
__create_mount_point ${I}
fsck.ext2 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext2)
;;
(*ext3*)
__create_mount_point ${I}
fsck.ext3 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext3)
;;
(*ext4*)
__create_mount_point ${I}
fsck.ext4 -y ${I}
ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */
__log ${I}:mount (ext4)
;;
(*Unix\ Fast\ File*)
__create_mount_point ${I}
fsck_ufs -y ${I}
mount ${I} ${MNT}
__log ${I}:mount (ufs)
;;
(*)
case $( dd ${I} count=1 2 /dev/null | strings | head -1 ) in
(EXFAT)
__create_mount_point ${I}
mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */
__log ${I}:mount (ufs)
;;
(*) continue ;;
esac
;;
esac
__state_add ${I} $( mount | grep -m 1 ${MNT} | awk '{printf $1}'
) \ ${MNT} || continue
done
;;
(detach)
MOUNT=$( mount )
__state_lock
grep ${1} ${STATE} \
| while read DEV PROVIDER MNT
do
TARGET=$( echo ${MOUNT} | grep -E ^${PROVIDER} | awk '{print
$3}' ) [ -z ${TARGET} ] {
__state_remove ${MNT} ${STATE} ${LINE}
continue
}
umount -f ${TARGET}
unset TARGET
__state_remove ${MNT} ${STATE} ${LINE}
__log ${DEV}:umount
done
__state_unlock
__log /dev/${1}:detach
find ${MNTPREFIX} -type d -empty -delete
;;
esac
Not sure if you've looked at disktype in sysutils
but it may be useful to you.
Hi,
Should your script be written like an rc.d script, so that one can
enable/disable this automounting from /etc/rc.conf?
Nice,
Some comments:
Instead of requiring modification to /etc/devd.conf why not just put a
plugin conf-file in /etc/devd/ - well even better put in
/usr/local/etc/devd/ - that way your devd.conf modifications are not
lost upon patching/updating base os.
There is an existing port called automounter by Dominic Fandrey which
is much similar to your work.
You can get inspired of how he places his devd.conf in /usr/local/etc/devd/
His automounter also works with disk labels (as found in /dev/ufs/ and
/dev/msdosfs/ etc)
You should consider make a port out of your work.
/Uffe
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: devd based AUTOMOUNTER
On (18/02/2012 10:48), vermaden wrote:
Added a check if ntfs-3g is available, if not then mount_ntfs is used instead.
Added deleting of empty directories at ${MNTPREFIX}.
Added ${MNTPREFIX} to be set to /mnt or /media according to preference
#! /bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
MNTPREFIX=/media
LOG=/var/log/automount.log
STATE=/var/run/automount.state
DATEFMT=%Y-%m-%d %H:%M:%S
__create_mount_point() { # /* 1=DEV */
MNT=${MNTPREFIX}/$( basename ${1} )
mkdir -p ${MNT}
}
__state_lock() {
while [ -f ${STATE}.lock ]; do sleep 0.5; done
: ${STATE}.lock
}
Why not keep it stateless, unmounting by hand would kill integrity.
Usage of `file` is a big security concern.
I think geom config and list of mounted file systems should be
sufficient for collecting information at runtime. Although it may not be
that easy for disks without partitioning.
I'm using a python script for mounting/unmounting removable disks,
but having similar tool written in sh would be great.
https://github.com/glk/mmount
Thanks,
Gleb.
__state_unlock() {
rm ${STATE}.lock
}
__state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */
__state_lock
grep -E ${3} ${STATE} 1 /dev/null 2 /dev/null {
__log ${1}:duplicated '${STATE}'
return 1
}
echo ${1} ${2} ${3} ${STATE}
__state_unlock
}
__state_remove() { # /* 1=MNT 2=STATE 3=LINE */
BSMNT=$( echo ${1} | sed 's/\//\\\//g' )
sed -i '' /${BSMNT}\$/d ${2}
}
__log() { # /* @=MESSAGE */
echo $( date +${DATEFMT} ) ${@} ${LOG}
}
case ${2} in
(attach)
for I in /dev/${1}*
do
case $( file -L -s ${I} | sed -E 's/label:\ \.*\//g' ) in
(*NTFS*)
dd ${I} count=1 2 /dev/null \
| strings \
| head -1 \
| grep -q NTFS {
__create_mount_point ${I}
which ntfs-3g 1 /dev/null 2 /dev/null {
ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */
} || {
mount_ntfs ${I} ${MNT}
}
__log ${I}:mount (ntfs)
}
;;
(*FAT*)
dd ${I} count=1 2 /dev/null \
| strings \
| grep -q FAT32 {
__create_mount_point ${I}
fsck_msdosfs -y ${I}
mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I}
${MNT}
__log ${I}:mount (fat)
}
;;
(*ext2*)
__create_mount_point ${I}
fsck.ext2 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext2)
;;
(*ext3*)
__create_mount_point ${I}
fsck.ext3 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext3)
;;
(*ext4*)
__create_mount_point ${I}
fsck.ext4 -y ${I}
ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */
__log ${I}:mount (ext4)
;;
(*Unix\ Fast\ File*)
__create_mount_point ${I}
fsck_ufs -y ${I}
mount ${I} ${MNT}
__log ${I}:mount (ufs)
;;
(*)
case $( dd ${I} count=1 2 /dev/null | strings | head -1 ) in
(EXFAT)
__create_mount_point ${I}
mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */
__log ${I}:mount (ufs)
;;
(*) continue ;;
esac
;;
esac
__state_add ${I} $( mount | grep -m 1 ${MNT} | awk '{printf $1}' ) \
${MNT} || continue
done
;;
(detach)
MOUNT=$( mount )
__state_lock
grep ${1} ${STATE} \
| while read DEV PROVIDER MNT
do
TARGET=$( echo ${MOUNT} | grep -E ^${PROVIDER} | awk '{print
$3}' )
[ -z ${TARGET} ] {
__state_remove ${MNT} ${STATE} ${LINE}
continue
}
umount -f ${TARGET}
unset TARGET
__state_remove ${MNT} ${STATE} ${LINE}
__log ${DEV}:umount
done
__state_unlock
__log /dev/${1}:detach
find ${MNTPREFIX} -type d -empty -delete
;;
esac
Not sure if you've looked at disktype in sysutils
but it may be useful to you.
I will get look into that, thanks ;)
Neat scripts!
Matt
Thanks mate.
Regards,
vermaden
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
callouts precision
Just want to double-check myself. It seems that currently, thanks to event timers, we mostly should be able to schedule a hardware timer to fire at almost arbitrary moment with very fine precision. OTOH, our callout subsystem still seems to be completely tick oriented in the sense that all timeouts are specified and kept in ticks. As a result, it's impossible to use e.g. nanosleep(2) with a precision better than HZ. How deeply ticks are ingrained into callout(9)? Are they used only as a measure of time? Or are there any dependencies on them being integers, like for indexing, etc? In other words, how hard it would be to replace ticks with e.g. bintime as an internal representation of time in callout(9) [leaving interfaces alone for the start]? Is it easier to retrofit that code or to replace it with something new? Thank you. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 8 to 9: Kernel modularization -- did it change?
Very very inefficient BIOS and loader behaviour? I'm not sure libufs is caching anything? Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: callouts precision
On 18.02.2012 21:05, Andriy Gapon wrote: Just want to double-check myself. It seems that currently, thanks to event timers, we mostly should be able to schedule a hardware timer to fire at almost arbitrary moment with very fine precision. OTOH, our callout subsystem still seems to be completely tick oriented in the sense that all timeouts are specified and kept in ticks. As a result, it's impossible to use e.g. nanosleep(2) with a precision better than HZ. How deeply ticks are ingrained into callout(9)? Are they used only as a measure of time? Or are there any dependencies on them being integers, like for indexing, etc? In other words, how hard it would be to replace ticks with e.g. bintime as an internal representation of time in callout(9) [leaving interfaces alone for the start]? Is it easier to retrofit that code or to replace it with something new? Pending callouts are now stored in large array of unsorted lists, where last bits of callout time is the array index. It is quite effective for insert/delete operation. It is ineffective for getting next event time needed for new event timers, but it is rare operation. Using arbitrary time values in that case is very problematic. It would require complete internal redesign. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: devd based AUTOMOUNTER
On Sat, Feb 18, 2012 at 06:06:23PM +0100, Uffe Jakobsen wrote:
On 2012-02-18 14:09, Hans Petter Selasky wrote:
On Saturday 18 February 2012 10:48:11 vermaden wrote:
Added a check if ntfs-3g is available, if not then mount_ntfs is used
instead. Added deleting of empty directories at ${MNTPREFIX}.
Added ${MNTPREFIX} to be set to /mnt or /media according to preference
#! /bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
MNTPREFIX=/media
LOG=/var/log/automount.log
STATE=/var/run/automount.state
DATEFMT=%Y-%m-%d %H:%M:%S
__create_mount_point() { # /* 1=DEV */
MNT=${MNTPREFIX}/$( basename ${1} )
mkdir -p ${MNT}
}
__state_lock() {
while [ -f ${STATE}.lock ]; do sleep 0.5; done
: ${STATE}.lock
}
__state_unlock() {
rm ${STATE}.lock
}
__state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */
__state_lock
grep -E ${3} ${STATE} 1 /dev/null 2 /dev/null {
__log ${1}:duplicated '${STATE}'
return 1
}
echo ${1} ${2} ${3} ${STATE}
__state_unlock
}
__state_remove() { # /* 1=MNT 2=STATE 3=LINE */
BSMNT=$( echo ${1} | sed 's/\//\\\//g' )
sed -i '' /${BSMNT}\$/d ${2}
}
__log() { # /* @=MESSAGE */
echo $( date +${DATEFMT} ) ${@} ${LOG}
}
case ${2} in
(attach)
for I in /dev/${1}*
do
case $( file -L -s ${I} | sed -E 's/label:\ \.*\//g' ) in
(*NTFS*)
dd ${I} count=1 2 /dev/null \
| strings \
| head -1 \
| grep -q NTFS {
__create_mount_point ${I}
which ntfs-3g 1 /dev/null 2 /dev/null {
ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */
} || {
mount_ntfs ${I} ${MNT}
}
__log ${I}:mount (ntfs)
}
;;
(*FAT*)
dd ${I} count=1 2 /dev/null \
| strings \
| grep -q FAT32 {
__create_mount_point ${I}
fsck_msdosfs -y ${I}
mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I}
${MNT} __log ${I}:mount (fat)
}
;;
(*ext2*)
__create_mount_point ${I}
fsck.ext2 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext2)
;;
(*ext3*)
__create_mount_point ${I}
fsck.ext3 -y ${I}
mount -t ext2fs ${I} ${MNT}
__log ${I}:mount (ext3)
;;
(*ext4*)
__create_mount_point ${I}
fsck.ext4 -y ${I}
ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */
__log ${I}:mount (ext4)
;;
(*Unix\ Fast\ File*)
__create_mount_point ${I}
fsck_ufs -y ${I}
mount ${I} ${MNT}
__log ${I}:mount (ufs)
;;
(*)
case $( dd ${I} count=1 2 /dev/null | strings | head -1 ) in
(EXFAT)
__create_mount_point ${I}
mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */
__log ${I}:mount (ufs)
;;
(*) continue ;;
esac
;;
esac
__state_add ${I} $( mount | grep -m 1 ${MNT} | awk '{printf $1}'
) \ ${MNT} || continue
done
;;
(detach)
MOUNT=$( mount )
__state_lock
grep ${1} ${STATE} \
| while read DEV PROVIDER MNT
do
TARGET=$( echo ${MOUNT} | grep -E ^${PROVIDER} | awk
'{print
$3}' ) [ -z ${TARGET} ] {
__state_remove ${MNT} ${STATE} ${LINE}
continue
}
umount -f ${TARGET}
unset TARGET
__state_remove ${MNT} ${STATE} ${LINE}
__log ${DEV}:umount
done
__state_unlock
__log /dev/${1}:detach
find ${MNTPREFIX} -type d -empty -delete
;;
esac
Not sure if you've looked at disktype in sysutils
but it may be useful to you.
Hi,
Should your script be written like an rc.d script, so that one can
enable/disable this automounting from /etc/rc.conf?
Nice,
Some comments:
Instead of requiring modification to /etc/devd.conf why not just put a
plugin conf-file in /etc/devd/ - well even better put in
/usr/local/etc/devd/ - that way your devd.conf modifications are not
lost upon patching/updating base os.
There is an existing port called automounter by Dominic Fandrey which
is much similar to your work.
You can get inspired of how he places his devd.conf in /usr/local/etc/devd/
His automounter also works with disk labels (as found in /dev/ufs/ and
/dev/msdosfs/ etc)
You should consider make a port out of your work.
And please don't hardcode
Re: callouts precision
on 18/02/2012 21:42 Alexander Motin said the following: On 18.02.2012 21:05, Andriy Gapon wrote: Just want to double-check myself. It seems that currently, thanks to event timers, we mostly should be able to schedule a hardware timer to fire at almost arbitrary moment with very fine precision. OTOH, our callout subsystem still seems to be completely tick oriented in the sense that all timeouts are specified and kept in ticks. As a result, it's impossible to use e.g. nanosleep(2) with a precision better than HZ. How deeply ticks are ingrained into callout(9)? Are they used only as a measure of time? Or are there any dependencies on them being integers, like for indexing, etc? In other words, how hard it would be to replace ticks with e.g. bintime as an internal representation of time in callout(9) [leaving interfaces alone for the start]? Is it easier to retrofit that code or to replace it with something new? Pending callouts are now stored in large array of unsorted lists, where last bits of callout time is the array index. It is quite effective for insert/delete operation. It is ineffective for getting next event time needed for new event timers, but it is rare operation. Using arbitrary time values in that case is very problematic. It would require complete internal redesign. I see. Thank you for the insight! One possible hack that I can think of is to use pseudo-ticks in the callout implementation instead of real ticks. E.g. such a pseudo-tick could be set equal to 1 microsecond instead of 1/hz (it could be tunable). Then, of course, instead of driving the callouts via hardclock/softclock, they would have to be driven directly from event timers. And they would have to use current microseconds uptime instead of ticks, obviously. This would also require a revision of types used to store timeout values. Current 'int' would not be adequate anymore, it seems. It looks like Timer_Wheel_T from ACE has some useful enhancements in this direction. BTW, it seems that with int ticks and HZ of 1000, ticks would overflow from INT_MAX to INT_MIN in ~24 days. I can imagine that some code might get confused by such an overflow. But that's a different topic. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 8 to 9: Kernel modularization -- did it change?
,--- b. f. (Sat, 18 Feb 2012 20:50:01 +) * | Most of these questions are more suitable for the freebsd-stable or | freebsd-questions mailing lists, rather than freebsd-hackers. I hesitated about starting this 8 to 9 thread here or on *-stable, and decided to use this list only because I had started another 8 to 9 thread re BIOS (applicable to current or legacy) on this list a couple of days before. So, it's here for consistency with the first thread but would be there otherwise. Don't mean I was right... Thank you for your very detailed response -- I will follow your advice and documentation pointers! -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: xargs short-circuit
On Tue, Feb 14, 2012 at 3:25 PM, Matthew Story matthewst...@gmail.comwrote: On Tue, Feb 14, 2012 at 2:37 PM, Matthew Story matthewst...@gmail.comwrote: On Tue, Feb 14, 2012 at 2:35 PM, Jilles Tjoelker jil...@stack.nl wrote: On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote: After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo $*; echo exit 1' worker || echo $? 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. As per xargs(1), you can do this by having the command exit on a signal or with a value of 255. exit 255 with -P, and SIGTERM (with or without -P) causes FreeBSD xargs to orphan, is this desirable behavior? findutils xargs orphans on 255 and SIGTERM (with -P), but does not orphan without -P when SIGTERM is sent. I would expect xargs to propegate the signal, or wait, although the man page does say immediately, the POSIX specification is less clear ... this makes it more-or-less unsuitable for my needs, but i guess i could do something like: ... | xargs sh -c '... exit 255;' if [ $? -ne 0 ]; then wait # cleanup exit 1 fi I have patched xargs behavior on exit 255 from utility, or termination of utility via signal to wait on existing utility processes before exiting 1. This make the exit 255 behavior much more predictable. I sent a lengthier explanation of the patch and reasoning to arch@, but figured I would follow up in thread as well. Patch available here: http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.patch.txt Hoping this patch will make it back into xargs, it makes exit 255 predictable with -P 1. Yes indeed it does ... should have scoured further, thanks! -- Jilles Tjoelker -- regards, matt -- regards, matt -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 8 to 9: Kernel modularization -- did it change?
Most of these questions are more suitable for the freebsd-stable or freebsd-questions mailing lists, rather than freebsd-hackers. Alex Goncharov wrote: What I see in 9 now is very confusing for me; e.g.: * Why 'snd_hda.ko' even exists, if the whole 'snd_hda' implementation lives in 'kernel' now? If not the whole, why is it split between 'kernel' and 'snd_hda.ko'? The implementation is not split between the kernel and the module: the snd_hda components are redundant. By default, most of the kernel modules are built and installed, even those present in GENERIC, unless one removes them from the build with MODULES_OVERRIDE or WITHOUT_MODULES (see, for example, make.conf(5)). This is because users often build one or more kernels that may not have all of the components that are in GENERIC. You can easily remove the modules that you don't want. * Why did 'snd' earn the honor to live in 'kernel', but 'linux.ko' did not? Because some people requested it, and no developer objected. Different users have different requirements, and most people can find parts of GENERIC that they don't want or need. Fortunately, users can easily build a custom kernel. If you don't want to be bothered with constructing a minimal custom kernel, but just want to remove a few components from GENERIC, you could use a simple custom kernel configuration like: include GENERIC ident MUTEGENERIC nodevice sound , snd_es137x , snd_hda , snd_ich , snd_uaudio , snd_vida8233 See, for example, config(5). * And what about CAM? ... Should I now (in 9) have: ... atapicam_load=YES ... as I had in 8, or it's no longer necessary because of the above extract from /usr/src/sys/amd64/conf/GENERIC? If you are using ATA_CAM, then you should not be using atapicam. I suspect that an explicit discussion of this is missing from some of the manpages because developers were planning to remove the old ATA code, and didn't want to spend a lot of time rewriting those documents, only to change or remove them later. But this has been mentioned several times on various lists, and is documented in src/sys/conf/NOTES: # ATA_CAM: Turn ata(4) subsystem controller drivers into cam(4) # interface modules. This deprecates all ata(4) # peripheral device drivers (atadisk, ataraid, atapicd, # atapifd, atapist, atapicam) and all user-level APIs. # cam(4) drivers and APIs will be connected instead The cd(4) driver in 9.0 should work adequately for most CDs, although you may want to add some post-release fixes from 9-STABLE, like: http://svnweb.FreeBSD.org/base?view=revisionrevision=230014 ... | I keep hoping that if I repeat this enough times that people will get | the word. :) Because loading modules through loader.conf is | veeryy slooww I added an rc.d script called | kld that will load the specified modules after disks are mounted. This | is at least an order of magnitude faster. Look for kld_list in | rc.conf(5) if you want the details, but the short version is that you | just do something like, kld_list=umass coretemp ichwd linux nvidia. | This is in all the -stable branches (including 7), is already in 9.0, | and will be in 8.3. I will use this -- thank you! You should be aware that kld_list doesn't always work. For example, my Nvidia nForce MCP61 network adapter works with nfe(4) when I load if_nfe.ko from loader.conf, but fails to function properly if the same module is loaded via kld_list, spamming the console with messages like: ... kernel: nfe0: watchdog timeout (missed Tx interrupts) -- recovering when I attempt to establish a connection over it. b. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 8 to 9: Kernel modularization -- did it change?
On 18 February 2012 12:50, b. f. bf1...@googlemail.com wrote: I will use this -- thank you! You should be aware that kld_list doesn't always work. For example, my Nvidia nForce MCP61 network adapter works with nfe(4) when I load if_nfe.ko from loader.conf, but fails to function properly if the same module is loaded via kld_list, spamming the console with messages like: ... kernel: nfe0: watchdog timeout (missed Tx interrupts) -- recovering when I attempt to establish a connection over it. Is there a PR for this? Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote: 1. Incidentally, what exactly does constitute a major release? That point in time where we guarantee that we break a certain degree of backwards compatibility. (Well, that's the key component. Feature- additions ride on top of that.) 2. Is there a reason to update the numbers so quickly? Yes, so that we don't have to keep supporting backwards compatibility for as long a period (see 1) -- it's a significant burden to maintain. It's necessary to do these as we rework things like network layers for higher performance, rework wireless to work with modern devices, and other high-demand items. 3. Could a higher bar be set to reach a major release than simply temporal objectives? Yes. We did that with 5.x, and blew it big-time. The goal of rewrite the entire system to support SMP in a scalable, reliable fashion was simply too aggressive. It led to ~5 years between major releases, and by that time the system had changed very dramatically (SMP, suspend/resume, IIRC GEOM, and too many other things to list). It was a huge jump and the learning curve for upgrading was way too large. We lost userbase. Also, keeping 5 years between major releases led to very high developer frustration. Why work on something when it will take 4+ years to even see the light of day? This is why we moved to the time-based releases. 18 months was seen as a compromise between all the various demands. Even so, we are almost exactly at 24 months in practice; see the graphs I updated last month as a result of all the recent discussion: http://people.freebsd.org/~linimon/schedule/ My own view is that 5 years between major releases is not going to happen, due to how painful the 5.x experience was for all concerned. But as I'm not a src committer, I'm not one of the people who will be picking the interval for our major-branch timeline. I just try to graph it as it goes by. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
The individual maintainers of each architecture have the right to make a PRE-RELEASE of the system at any time. Come to think of it, anyone who can has that right- that is to make a pre-release. On 2/18/12, Mark Linimon lini...@lonesome.com wrote: On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote: 1. Incidentally, what exactly does constitute a major release? That point in time where we guarantee that we break a certain degree of backwards compatibility. (Well, that's the key component. Feature- additions ride on top of that.) 2. Is there a reason to update the numbers so quickly? Yes, so that we don't have to keep supporting backwards compatibility for as long a period (see 1) -- it's a significant burden to maintain. It's necessary to do these as we rework things like network layers for higher performance, rework wireless to work with modern devices, and other high-demand items. 3. Could a higher bar be set to reach a major release than simply temporal objectives? Yes. We did that with 5.x, and blew it big-time. The goal of rewrite the entire system to support SMP in a scalable, reliable fashion was simply too aggressive. It led to ~5 years between major releases, and by that time the system had changed very dramatically (SMP, suspend/resume, IIRC GEOM, and too many other things to list). It was a huge jump and the learning curve for upgrading was way too large. We lost userbase. Also, keeping 5 years between major releases led to very high developer frustration. Why work on something when it will take 4+ years to even see the light of day? This is why we moved to the time-based releases. 18 months was seen as a compromise between all the various demands. Even so, we are almost exactly at 24 months in practice; see the graphs I updated last month as a result of all the recent discussion: http://people.freebsd.org/~linimon/schedule/ My own view is that 5 years between major releases is not going to happen, due to how painful the 5.x experience was for all concerned. But as I'm not a src committer, I'm not one of the people who will be picking the interval for our major-branch timeline. I just try to graph it as it goes by. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 8 to 9: Kernel modularization -- did it change?
On 02/18/2012 10:43, per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: loading modules through loader.conf is veeryy slooww ... Is it noticeably slower to load (say) a 6MB kernel + 2MB of modules than to load an 8MB kernel? I don't know, that wasn't the problem I was trying to solve. If your question is, 6 + 2-in-loader-conf then I imagine that it would be about the same speed, maybe a little slower due to extra file open-read-close cycles. If it's 6 + 2-in-kld_list then I imagine it would be quite a bit faster than an 8 M kernel, but I look forward to the results of your testing. :) Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: callouts precision
On 18.02.2012 22:40, Andriy Gapon wrote: on 18/02/2012 21:42 Alexander Motin said the following: On 18.02.2012 21:05, Andriy Gapon wrote: Just want to double-check myself. It seems that currently, thanks to event timers, we mostly should be able to schedule a hardware timer to fire at almost arbitrary moment with very fine precision. OTOH, our callout subsystem still seems to be completely tick oriented in the sense that all timeouts are specified and kept in ticks. As a result, it's impossible to use e.g. nanosleep(2) with a precision better than HZ. How deeply ticks are ingrained into callout(9)? Are they used only as a measure of time? Or are there any dependencies on them being integers, like for indexing, etc? In other words, how hard it would be to replace ticks with e.g. bintime as an internal representation of time in callout(9) [leaving interfaces alone for the start]? Is it easier to retrofit that code or to replace it with something new? Pending callouts are now stored in large array of unsorted lists, where last bits of callout time is the array index. It is quite effective for insert/delete operation. It is ineffective for getting next event time needed for new event timers, but it is rare operation. Using arbitrary time values in that case is very problematic. It would require complete internal redesign. I see. Thank you for the insight! One possible hack that I can think of is to use pseudo-ticks in the callout implementation instead of real ticks. E.g. such a pseudo-tick could be set equal to 1 microsecond instead of 1/hz (it could be tunable). Then, of course, instead of driving the callouts via hardclock/softclock, they would have to be driven directly from event timers. And they would have to use current microseconds uptime instead of ticks, obviously. This would also require a revision of types used to store timeout values. Current 'int' would not be adequate anymore, it seems. I don't think it will work. With so high frequency it will make callouts distribution over the array almost random. While insert / remove operations will still be cheap, search for the next event will be 1000 times more expensive. Unless you propose increase array size 1000 times, it will not be better then just using single unsorted link, It looks like Timer_Wheel_T from ACE has some useful enhancements in this direction. BTW, it seems that with int ticks and HZ of 1000, ticks would overflow from INT_MAX to INT_MIN in ~24 days. I can imagine that some code might get confused by such an overflow. But that's a different topic. Probably you are right. I've seen few dangerous comparisons in ULE code. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
