RFC: A trial io provider for DTrace...

Howdy,

I have just put up the first patch that can give you something similar
to the io provider in DTrace.  The patch is against HEAD of about a
week ago.

You can find the patch here: freebsd.org:

http://people.freebsd.org/~gnn/dtio_provider.diff

Note that you need to create a src/sys/modules/dtrace/dtio/ directory
for this patch, since patch doesn't seem to create directories for me.

The arguments are not exactly the same as in Solaris, for instance I
don't yet support the fileinfo_t, but, you can get to the devstat and
bio structures via args[0] and args[1] respectively.

Here is an example of it working:

dtrace -n 'io:::start /args[0] != 0/{ trace(args[0]->bio_bcount)}'

Remember you need to be root to use DTrace.

I need to clean this up and get the translators working properly
before I can check this in.

Also, note that this patch doesn't catch all I/O, but should get most
of it, as it's hooked into the devstat system.

I will be adding manual pages for the internals of DTrace to our

headers that use "struct bintime"

"struct bintime" is enabled only by __BSD_VISIBLE. However, there are
a few headers that use "struct bintime" without __BSD_VISIBLE:

sys/arm/include/cpu.h
sys/dev/iscsi/initiator/iscsivar.h
sys/geom/journal/g_journal.h
sys/sys/dtrace_bsd.h
sys/sys/devicestat.h
sys/sys/timeet.h
sys/sys/bio.h
sys/opencrypto/cryptodev.h

Should the definitions that use "struct bintime" be __BSD_VISIBLE too?
 Or maybe "struct bintime" be defined unconditionally?

Or perhaps we could have "struct __bintime" and use that for system headers?

--

-- 
Robert Millan
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

References to non-existent block devices

I've noticed that although block devices were removed from FreeBSD
quite some time ago, there are still lots of references to them in man
pages and comments.  I've raised docs/167832 to basically change these
references to "disk devices".  I would appreciate a few more eyes
having a look over my suggested changes.

--

-- 
Peter Jeremy

[patch] halt/reboot/shutdown cleanup

There is duplication of code between sbin/reboot and init: both can
cleanly shut down the system, for some value of "cleanly". Because the
code in init is activated by the kernel (sending a signal to init), it
makes sense to keep that and remove the duplicate from sbin/reboot. This
also ensures that /etc/rc.shutdown is executed in all "clean" shutdowns.

Before 9.0, init could not shut down the system 100% correctly during
single user mode (for example, it inappropriately ran /etc/rc.shutdown),
but this has been fixed.

Also, the normal forms of halt and reboot will now call shutdown so
users get a clear message of the event.

Halt and reboot still support the -q option to invoke reboot(2) without
anything else. The -d and -n options now require -q (because init is
signaled if -q is not used, and init will not do dump or nosync).

The -l option of halt and reboot now not only suppresses logging, but
also user notification. It does this by signaling init directly and not
going through shutdown.

The -o option of shutdown goes away because there does not seem any
point in executing halt or reboot if they are going to send the same
signal to init anyway.

diff --git a/include/paths.h b/include/paths.h
index 6503934..f93cf39 100644
--- a/include/paths.h
+++ b/include/paths.h
@@ -84,6 +84,7 @@

Inotify IN_CLOSE_WRITE Support

I tried inotifywait based on libinoitfy in the port. I noticed that the
most interesting event to me, IN_CLOSE_WRITE, doesn't get triggered. I'd
like to spend some to hack to get this supported. but I don't know where is
good start point.

IN_CLOSE_WRITE    File opened for writing was closed (*).

Anyone can give me some advice on this?

--

-- 
-Howard
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Allow small amount of memory be mlock()'ed by unprivileged process?

Hi,

I've recently read some documents saying that some other operating
systems would allow a small amount of memory be mlock()'ed by
unprivileged process.  This feature is useful for applications that
needs the semantics, e.g. when requesting for memory that holds
sensitive information like private keys, etc.

The current implementation of ours would just return EPERM when caller
is not the superuser, and enforce a limit for privileged processes
(which is set to infinity).

Is there any concern of changing this to allow a few memory pages be
locked and remove the limit when the calling process is superuser?

Cheers,
--

-- 
Xin LI <delphij <at> delphij.net>	https://www.delphij.net/
FreeBSD - The Power to Serve!		Live free or die

Switching /etc/*.db from bdb to tinycdb

Hi,

I plan to work on switching all the /etc/*.db files from bdb 1.85 to cdb (using
the tinycdb implementation)

Reason for doing that:
1/ we use the *.db files as a constant database on recreating them using
*_mkdb(8) commands
2/ bdb 1.85 database are endianness dependant which can cause problem if I want
pkgng to be able to create users when cross installing packages (like adding
packages in a mips eb chroot environment on an amd64 host)
3/ the tinycdb API is clean and easy to use (I find it easier and cleaner to
deal with it)
4/ tinycdb is public domain so not problem for us to use it.

On the side effects, I'm not sure this is relevant but tinycdb is also faster to
read then bdb 1.85.

How do I plan to do it.

I plan to import the read part or tinycdb into libc and the write part into
libutil (to avoid cluttering libc).

Why importing to libc? to allow all the get*ent to parse the /etc/*.db files.

How to implment it? slowly with backward compatibility:
for each kind of files: try to open with cdb, if fail fall back to bdb.

I plan to rewrite all the *_mkdb for make them use cdb.

Request for comments - NAND Framework & NandFS

Hi,

We work on integration our work on NAND Framework into -current.
Our project consist of:
- NAND Framework which allows treat NAND Flash Chip as storage devices,
- NANDSim which is kernel driver which emulates ONFI-compliant chip 
devices and userspace tool to configure/manage created devices,
- NandFs which is log filesystem which is targeted for NAND chip storage 
devices.

Currently our work is merged into "nand" branch under project directory 
(http://svnweb.freebsd.org/base/projects/nand/). Currently we are still 
working on fixing existing bugs and cleaning up the code. We are going 
to start merge in into HEAD on on May 7th.  I would like to ask you to 
review the code and let us know if you have any comments or concerns.

thanks,
grzesiek
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Increase DFLDSIZ on amd64?

Hi,

Is there any reason for DFLDSIZ being so low (128 MiB) on amd64?
We've recently had a bunch of trouble in Debian when attempting to run
the CMOR testsuite.  Its testcases require about ~700 MiB to pass.  We
also found references recommending higher values for applications like
SAP [2] or MySQL [3].

I understand on i386 there's a shortage of virtual memory, but on
amd64 there's plenty of it.  It seems this is already reflected on the
MAXDSIZ setting (32 GiB), but DFLDSIZ is still the same as on i386.
Wouldn't 32 GiB be a sound value as the default limit too?  Is there
any unreasonable cost or security consideration associated with
allocating so many pages?

Thanks

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661283
[2] http://www.freebsd.org/doc/handbook/sapr3.html#KERNELTUNING
[3] https://dev.mysql.com/doc/refman/5.0/en/freebsd.html

--

-- 
Robert Millan

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

[RFC] break out 'statfoo' from wlanstats/athstats into a shared library

Hi,

There's a statistics library which Sam used for a variety of networking tasks:

* wlanstats
* mwlstats
* athstats
* (npestats? What's npe?)

I've fixed some issues in athstats' copy of libstatfoo which I can
port elsewhere. But I can also see scenarios where I'd like to use
this library code in future statistics utilities that I'll write.

What I'd like to do is:

* break out the statfoo from these and create a libstatfoo, that's
built as part of the base system;
* teach wlanstats, mwlstats, athstats to use the system provided copy
of libstatfoo;
* migrate wlanstats out from tools into the base system.

Does anyone have any particular reason not to do this?

Adrian
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

EVENTHANDLER()'s

So many years ago (2004), you removed support for "fast" EVENTHANDLER() 
objects.  I was looking at this today and I kind of think we should actually 
undo that, but perhaps instead what we should do is make all EVENTHANDLER()'s 
"fast".  No one creates eventhandlers with dynamic names (nor have they ever 
AFAIK), they all have static names.  However, each time someone calls 
EVENTHANDLER_INVOKE() we do an O(n) loop with strcmp's to lookup the list by 
it's name via a string.  It seems to me that we would do just fine with having 
all the eventhandler lists be global variables like the old "fast" variants 
and the string "tag" passed to all the EVENTHANDLER macros would just be used 
to set the variable name (exactly like the old "fast" variants).  This would 
remove all the O(n) lookups, and we could further optimize _INVOKE() to not do 
any locking if the list is empty to avoid overhead in the case where there are 
no active hooks.

--

-- 
John Baldwin
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"