Re: How to change vnode operations ?
On Thu, 22 Apr 2010, Gleb Kurtsou wrote: Date: Thu, 22 Apr 2010 22:18:49 +0300 From: Gleb Kurtsou gleb.kurt...@gmail.com To: Lukáš Czerner czerner.lu...@gmail.com Cc: freebsd-hackers@freebsd.org Subject: Re: How to change vnode operations ? On (22/04/2010 16:02), Lukáš Czerner wrote: Hi all, this may sound a little odd, since I have noticed that there is much work done to not allow such a thing ($SUBJ). But may be you can help me and point me to the right direction. I am writing a kernel module with somewhat similar functionality like nullfs has, BUT it has to have some features which nullfs itself does not provide : 1. I need the new layer to completely hide underlaying layer so no one can bypass it. Is hypothetic 'mount -t mynullfs /a /a' good enough for you? I'm not sure what your goals are but completely finding underlaying filesystem won't be easy because of VFS_GET, getfh and other stuff operating with inode numbers. Well, it may be good enough, or not. Thats what I am trying to find out. Obviously there are problems, as you mentioned, which will not exist when I change the vop_vector of the vnode, but as I thought and you mentioned it as well, this is not very clean way. 2. Nullfs allows me to to overlay just one directory, but i want to include another directories and/or exclude subdirectories/files. 3. Nullfs just redirects vnode operations to lower layer, I need to catch that operation, do something (for example alter the arguments somehow etc..), pass the operation (with possibly altered arguments) to the lower layer, get the result and then return the result. I'd suggest to take a look at pefs: http://github.com/glk/pefs It's cryptographic stacked filesystem for FreeBSD. It changes file names, hides directory entries, modifies data from lower layer (encrypts or decrypts), supports mounting on same directory, etc. Thats great, thanks! I will look at it. The best way to do that (I think) is to change vnode operations of particular vnodes to point to functions defined in that module. At this point, I can catch any operations with the vnode and this is the base of what i want. So my question is. I there any clean way to chande vnode operations ? If not, is there any not so clean way ? Anyway I will appreciate any good idea how to do what I have described. Imho, stacked filesystem is the only right way to do it (see null, unionfs, pefs). OK. Thanks for pointing me to the pefs, it is interesting and looks like a good start. But I would appreciate more comment on the side of the whole idea about changing vnode operations from the kernel module. It is a little hacky, but aside this I do not see any bigger problems, do you ? Thanks. -Lukas___ 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: /etc in CVS
On Thu, Apr 22, 2010 at 04:41:27PM +0200 I heard the voice of Ulrich Spörlein, and lo! it spake thus: I have a .hg directory sitting in / for every machine I usually take care of. hgignore is of course set to *, so only explicitly added files are tracked. I do pretty much the same thing (except mine has .bzr/ and .bzrignore ;). Using the VCS to handle updates requires something a bit broader though. I HAVE considered it. You'd need to do the sort of 'make install' stuff mergemaster does to a tempdir, and make a branch there checking in the snapshots, and have your etc be a derived branch from that. That way you have all the VCS merge capabilities to do the merges and track where they came from. Mergemaster works well enough that I've given no serious thought beyond idle that would be cool thinking on the matter though 8-} -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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
Keyboard scancodes
I was recently given an original Happy Hacking Keyboard. As I sometimes work in the FreeBSD console, I wanted to have my usual console keymap adjusted to the new keyboard, but didn't know the scancode for the HHKB meta key (the diamond key). I couldn't find any program in base or ports that would show me the scancodes, so I ended up writing my own: http://hack.org/mc/hacks/kbdscan/ It's little more than a quick hack done while my baby daughter was napping, but it works for my purposes. The program sets the FreeBSD console keyboard in raw scancode mode and the terminal in raw mode without echo. It then shows scancodes of keys pressed and released. Five seconds of inactivity resets the keyboard and terminal to the original modes and quits the program. Nota bene: If the process receives any signals, it will currently leave the keyboard and console in the raw mode. When I was searching for information about this, I found a lot of similar questions on freebsd-questions and in other fora about similar problems, so I thought I should post about it. Please excuse me if this is inappropriate. Happy hacking, MC. -- http://hack.org/mc/ Use plain text e-mail, please. OpenPGP welcome, 0xE4C92FA5. ___ 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: How to change vnode operations ?
On (23/04/2010 08:10), Lukáš Czerner wrote: On Thu, 22 Apr 2010, Gleb Kurtsou wrote: Date: Thu, 22 Apr 2010 22:18:49 +0300 From: Gleb Kurtsou gleb.kurt...@gmail.com To: Lukáš Czerner czerner.lu...@gmail.com Cc: freebsd-hackers@freebsd.org Subject: Re: How to change vnode operations ? On (22/04/2010 16:02), Lukáš Czerner wrote: Hi all, this may sound a little odd, since I have noticed that there is much work done to not allow such a thing ($SUBJ). But may be you can help me and point me to the right direction. I am writing a kernel module with somewhat similar functionality like nullfs has, BUT it has to have some features which nullfs itself does not provide : 1. I need the new layer to completely hide underlaying layer so no one can bypass it. Is hypothetic 'mount -t mynullfs /a /a' good enough for you? I'm not sure what your goals are but completely finding underlaying filesystem won't be easy because of VFS_GET, getfh and other stuff operating with inode numbers. Well, it may be good enough, or not. Thats what I am trying to find out. Obviously there are problems, as you mentioned, which will not exist when I change the vop_vector of the vnode, but as I thought and you mentioned it as well, this is not very clean way. Why don't you like stacked filesystem approach? It's designed to solve the problem you are describing if I get it right. Although creating pefs-like filesystem altering data and names is not so easy within existing framework. 2. Nullfs allows me to to overlay just one directory, but i want to include another directories and/or exclude subdirectories/files. 3. Nullfs just redirects vnode operations to lower layer, I need to catch that operation, do something (for example alter the arguments somehow etc..), pass the operation (with possibly altered arguments) to the lower layer, get the result and then return the result. I'd suggest to take a look at pefs: http://github.com/glk/pefs It's cryptographic stacked filesystem for FreeBSD. It changes file names, hides directory entries, modifies data from lower layer (encrypts or decrypts), supports mounting on same directory, etc. Thats great, thanks! I will look at it. The best way to do that (I think) is to change vnode operations of particular vnodes to point to functions defined in that module. At this point, I can catch any operations with the vnode and this is the base of what i want. So my question is. I there any clean way to chande vnode operations ? If not, is there any not so clean way ? Anyway I will appreciate any good idea how to do what I have described. Imho, stacked filesystem is the only right way to do it (see null, unionfs, pefs). OK. Thanks for pointing me to the pefs, it is interesting and looks like a good start. But I would appreciate more comment on the side of the whole idea about changing vnode operations from the kernel module. It is a little hacky, but aside this I do not see any bigger problems, do you ? Changing vop_vector is too hackish for me. Basically, changing vnode operations is what stacked filesystems are about. Vnode operations are the top of the problem, you would also have to deal with parent lookup, namecache consistency and buffering, which is going to be complicated. I.e. you'd have to partially reimplement part of VFS layer. nullfs and unionfs pass vnode vobject (buffering layer) from lower layer, adding your own vobject to vnode would complicate filesystem significantly. Besides you won't be able to assign 2 vobjects (original and your own) to a single vnode if you decide to change operations vector. Thanks, Gleb. Thanks. -Lukas ___ 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: Bug with fixit live 8.0 memstick.img running on F1 after MBR
Hi Ken, cc hackers@, re@ On Wed, 2010-04-21 at 21:09 +0200, Julian H. Stacey wrote: Hi hackers@, No replies in over 4 days to this, so this is a repost,=20 I've also added re@ as newish memstick.img might interest them ? (The live command prompt on F4 wasn't much use, no ls yet.) echo * Ah Yes ! Sorry I'm so dyed in the wool I forgot, ( I tend to assume sh, even though FreeBSD went csh with internal echo maybe a decade back. ) (PS 'cat .' is another arcane trick in some other contexts :-) trying to do. There is a script named make-memstick.sh in /usr/src/release/scripts on head and stable/8 (it got added after 8.0-RELEASE was out) that I use to make the memstick images. ... OK, Thanks I'll take a look at your script, if I have something useful to contribute, will send-pr cc you. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.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: there is a way to avoid strict libraries linking?
On Thu, 22 Apr 2010 15:38:14 -0700 Steve Franks bahamasfra...@gmail.com wrote: It's much safer to just leave the libraries alone. __Just because you upgraded libpng doesn't mean that your old gtk binary will stop working (assuming you are using portupgrade or portmaster -w which preserves old About to get flamed, I know Untrue. Portupgrade deletes the old version of the port by default. The PNG upgrade was a major PITA, because I installed one new port that thought it had to have it. I'm sure 98% of the ports I then had to upgrade would have still worked just fine even if rebuilt against the old libpng. I think the complaint here is that the port dependencies system frequently gives the impression/enforces the rule that new ports will depend on whatever the most current version of everything is in the ports tree at the time they were built, forcing sort of a perpetual upgrade cycle. IMHO this is probably due to naive port maintainers (such as myself) incorrectly pointing a port at libpng.5 instead of any libpng, or libpng = 5. Once the ports tree is 'poisoned' in this fashion, there's really no going back. I'd sure vote for an audit of this behavior as a summer of code project. Long story short, anything that sounds fundamental gets bumped (png, jpeg, tcl, python, gtk, etc, etc), I just sit back and get ready to spend two or three days retrying portupgrade -akOf -mBATCH=yes until everything sticks. If you've got OO or KDE4 installed, you might just want to forget it and pkg_delete -f *, then start over. Setting FORCE_PKG_REGISTER in /etc/make.conf should mitigate such problems. I actually have both png-1.2.43 and png-1.4.1_1 installed and the old /usr/local/lib/libpng.so.5 is still there along with the new /usr/local/lib/libpng.so.6. -- Gary Jennejohn ___ 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: /sys/amd64/conf/GENERIC COMPAT_FREEBSD7 a prerequisite for COMPAT_IA32
Gary Jennejohn wrote:
Julian H. Stacey j...@berklix.com wrote:
Gary Jennejohn wrote:
Julian H. Stacey j...@berklix.com wrote:
Hi hack...@freebsd.org
with amd64, but not with i386,
/sys/amd64/conf/GENERIC COMPAT_FREEBSD7 is an undocemneted
pre-requisite for COMPAT_IA32
(so those who enable COMPAT_IA32 for ports/emulators, but disable
COMPAT_FREEBSD7 as they compile all binaries on upgrade, will trip
up on it as I did). Currently I see:
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../..
-I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h -fno-common -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000
-fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387
-mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-Werror ../../../compat/freebsd32/freebsd32_misc.c
cc1: warnings being treated as errors
../../../compat/freebsd32/freebsd32_misc.c: In function
'freebsd32_semsys':
../../../compat/freebsd32/freebsd32_misc.c:1420: warning: implicit
declaration of function 'freebsd7_freebsd32_semctl'
../../../compat/freebsd32/freebsd32_misc.c:1420: warning: nested extern
declaration of 'freebsd7_freebsd32_semctl'
...
../../../compat/freebsd32/freebsd32_misc.c:1845: error: dereferencing
pointer to incomplete type
*** Error code 1
It could be documented in GENERIC, but better to fix it. I could
dig through sources, but I think there's people closer to config
who would prefer to commit their own fix, rather than me write a patch ?
(Does that translate as I'm lazy ? ;-)
The switch is documented in /usr/src/UPDATING on my box. This is the
usual place for this kind of heads-up.
Thanks Gary,
It seems COMPAT_FREEBSD7 has more scope than [456]
( /usr/src/UPDATING I should read more often. )
But /usr/src/UPDATING is a transition log, as new things occur,
the entry re COMPAT_FREEBSD7 will get buried deeper.
Requirement from COMPAT_IA32 for COMPAT_FREEBSD7 applies with
amd64 but not i386, so I'd suggest that could be documented in
/sys/amd64/conf/GENERIC , eg
From
options COMPAT_FREEBSD7 # Compatible with FreeBSD7
To
options COMPAT_FREEBSD7 # Compatible with FreeBSD7, req. by
COMPAT_IA32
You're right. It's also in /sys/amd64/conf/NOTES, which is actually
the place where valid flags are supposed to be documented. GENERIC
actually has a different role. Note that I'm running -current, but
it should also be there on other releases.
COMPAT_FREEBSD7 is not in { 8.0-RELEASE stable current }
/sys/amd64/conf/NOTES
OK, thanks for pointing where it should go,
I will send a send-pr to add it
Cheers,
Julian
--
Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.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: /etc in CVS
On Friday 23 April 2010 2:50:15 am Matthew D. Fuller wrote: On Thu, Apr 22, 2010 at 04:41:27PM +0200 I heard the voice of Ulrich Spörlein, and lo! it spake thus: I have a .hg directory sitting in / for every machine I usually take care of. hgignore is of course set to *, so only explicitly added files are tracked. I do pretty much the same thing (except mine has .bzr/ and .bzrignore ;). Using the VCS to handle updates requires something a bit broader though. I HAVE considered it. You'd need to do the sort of 'make install' stuff mergemaster does to a tempdir, and make a branch there checking in the snapshots, and have your etc be a derived branch from that. That way you have all the VCS merge capabilities to do the merges and track where they came from. Mergemaster works well enough that I've given no serious thought beyond idle that would be cool thinking on the matter though 8-} etcupdate essentially seeks to do a simplified version of the vendor imports by just keeping the last two imports around so that each new import can be applied. This does mean it is more limited than a full source code control solution, but it also ends up being more lightweight. -- John Baldwin ___ 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
libc NLS, NFS mounted /usr/local, DHCP, no default route causes hangs
The changes to use NLS for strerror sometimes cause one of my virtual machines to deadlock. This virtual machine runs 9-CURRENT, acquires its IP address via DHCP (virtualbox host-only networking), has no default route and has /usr/local and /usr/home NFS mounted. When the DHCP lease expires such as by resetting the date after a VM saverestore, one of the route(8) commands executed by dhclient-script(8) fails and calls strerror(3). Following the default NLSPATH, catopen(3) looks in /usr/share/nls first; because the catalog is not there it then tries in /usr/local/share/nls which deadlocks because the network is not available. I currently use the attached patch which returns failure on any attempt to open a catalog for language C, but I think this is not correct. Am I using a configuration that is not supposed to work (NFS mounted /usr/local with DHCP in particular), or should this be fixed in some other way? -- Jilles Tjoelker ___ 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
regenerating /var/db/pkg
Aryeh M. Friedman writes: I acciddentally rm'ed my /var/db/pkg and want to know is it possible to rgenerate it (I have portmaster and portupgrade installed) (I'm assuming you have _completely_ deleted the contents of /var/db/pkg.) If you have not deleted /usr/ports/distfiles, this will give you a starting place. Mind you, some of the distfile names bear scant relation to the port names ... but they're usually not that hard to track down. The advice to start with a big one - OpenOffice, KDE, etc. - is also sound. Robert Huff (who used this method successfully a couple of years ago) ___ 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: libc NLS, NFS mounted /usr/local, DHCP, no default route causes hangs
On Fri, Apr 23, 2010 at 04:17:36PM +0200, Jilles Tjoelker wrote:
The changes to use NLS for strerror sometimes cause one of my virtual
machines to deadlock. This virtual machine runs 9-CURRENT, acquires its
IP address via DHCP (virtualbox host-only networking), has no default
route and has /usr/local and /usr/home NFS mounted.
When the DHCP lease expires such as by resetting the date after a VM
saverestore, one of the route(8) commands executed by
dhclient-script(8) fails and calls strerror(3). Following the default
NLSPATH, catopen(3) looks in /usr/share/nls first; because the catalog
is not there it then tries in /usr/local/share/nls which deadlocks
because the network is not available.
I currently use the attached patch which returns failure on any attempt
to open a catalog for language C, but I think this is not correct.
Am I using a configuration that is not supposed to work (NFS mounted
/usr/local with DHCP in particular), or should this be fixed in some
other way?
The patch:
Index: lib/libc/nls/msgcat.c
===
--- lib/libc/nls/msgcat.c (revision 206760)
+++ lib/libc/nls/msgcat.c (working copy)
@@ -138,6 +138,9 @@
lang = C;
}
+ if (strcmp(lang, C) == 0)
+ NLRETERR(ENOENT);
+
/* Try to get it from the cache first */
RLOCK(NLERR);
SLIST_FOREACH(np, cache, list) {
--
Jilles Tjoelker
___
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: libc NLS, NFS mounted /usr/local, DHCP, no default route causes hangs
On Fri, Apr 23, 2010 at 04:40:36PM +0200, Jilles Tjoelker wrote:
The patch:
Index: lib/libc/nls/msgcat.c
===
--- lib/libc/nls/msgcat.c (revision 206760)
+++ lib/libc/nls/msgcat.c (working copy)
@@ -138,6 +138,9 @@
lang = C;
}
+ if (strcmp(lang, C) == 0)
+ NLRETERR(ENOENT);
+
/* Try to get it from the cache first */
RLOCK(NLERR);
SLIST_FOREACH(np, cache, list) {
This is wrong. Just because you are in the C locale doesn't mean that
you don't have a message cataloge.
Joerg
___
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: c question
- use a matrix is faster than use a linked list? For what? For insertion and deletion no - linked list is faster. For sequential access they are the same speed (forgetting look-ahead caching). For random access matrix is faster. ___ 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: I want to participate in some FreeBSD project
Quoting Equixen- equi...@gmail.com (from Mon, 12 Apr 2010 12:05:12 +0530): Hello! I am a 3rd year B.Tech (Computer Science) student. I want to participate in some open source project during my summer vacations. I thought about going the Google summer of code way but due to limited knowledge and examinations during the 1st month of the program timeline didn't participate in it. However, I still want to help with the FreeBSD projects. I understand that there will be no stipend and possibly will not be provided any mentor but I request the FreeBSD team to kindly consider me for any of their ongoing project (I might help some student selected via Google SoC). I'd like at our ideas page (http://wiki.freebsd.org/IdeasPage) The way I find my ideas is by reading the mailing list and looking for complaints or suggestions. When I feel capable I provide a patch implementing whatever needed to be done. Once in a while I find something lacking on my own and provide a patch for that. ___ 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: RevLin OS: Help wanted
on 22/04/2010 18:04 RevLin Software said the following: Hello All My name is Patrick Quinn I am currently part of a team working on a new operating system called RevLin OS. RevLin OS will use a new desktop environment called RaVe that is coded almost entirely in web language (Css html5 and Javascript ) with native back ends, all running locally inside a Webkit based run time environment. However we are on the fence with the kernel. Initially we wanted to base the kernel ( named PopCorn) on Linux due to its support for various desktop hardware and platforms, but now we feel that going with FreeBSD or maybe even Haiku would be a better plan. I was wondering if any BSD developers would be willing to come aboard and work on the kernel with us? More information about the OS can be found over at my blog http://p-quinn.com/entries/report/report-what-is-revlin-os-and-what-are-its-benefits . If you have any other more technical questions feel free to ask. Patrick, RevLin/RaVe sounds like a very interesting project in line with modern trends. I am curious what is your motivation to look for alternatives to Linux and specifically for your interest in FreeBSD. Is it based on some technical aspects, or license, or something else? Thanks a lot! -- 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: c question
On Fri, Apr 23, 2010 at 06:18:46PM +0300, Eitan Adler wrote: - use a matrix is faster than use a linked list? For what? For insertion and deletion no - linked list is faster. For sequential access they are the same speed (forgetting look-ahead caching). For random access matrix is faster. Actually -- it depends. Removing the tail and inserting at tail is amortised constant time for arrays if done using the double-on-full trick. In that case, array can be the faster datastructure too. Joerg ___ 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: c question
On Friday 23 April 2010 17:40:12 Joerg Sonnenberger wrote: On Fri, Apr 23, 2010 at 06:18:46PM +0300, Eitan Adler wrote: - use a matrix is faster than use a linked list? For what? For insertion and deletion no - linked list is faster. For sequential access they are the same speed (forgetting look-ahead caching). For random access matrix is faster. Actually -- it depends. Removing the tail and inserting at tail is amortised constant time for arrays if done using the double-on-full trick. In that case, array can be the faster datastructure too. Random deletes can be made O(1) if you don't care about the order of the elements in an array. - Pieter ___ 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
idle threads
I'm looking at kern_idle.c in stable/7 and I don't quite follow how idle threads work. The kthread_create(9) call does not pass in a function pointer, so what code does a processor run when there is no other runnable thread? Thanks, matthew ___ 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: idle threads
2010/4/24 Matthew Fleming matthew.flem...@isilon.com:
I'm looking at kern_idle.c in stable/7 and I don't quite follow how idle
threads work. The kthread_create(9) call does not pass in a function
pointer, so what code does a processor run when there is no other
runnable thread?
In STABLE_7:
...
#ifdef SMP
SLIST_FOREACH(pc, cpuhead, pc_allcpu) {
error = kthread_create(sched_idletd, NULL, p,
RFSTOPPED | RFHIGHPID, 0, idle: cpu%d, pc-pc_cpuid);
pc-pc_idlethread = FIRST_THREAD_IN_PROC(p);
#else
error = kthread_create(sched_idletd, NULL, p,
RFSTOPPED | RFHIGHPID, 0, idle);
PCPU_SET(idlethread, FIRST_THREAD_IN_PROC(p));
#endif
...
then they rightly passes sched_idletd(). Any scheduler may define its
own version of sched_idletd().
NULL is just the argument passed that is not meaningful.
Or maybe I'm not understanding your question?
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
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: idle threads
then they rightly passes sched_idletd(). Any scheduler may define its own version of sched_idletd(). Oops, youre right, I was just unable to read at the end of the day on Friday. Thanks! matthew ___ 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
What tty changes - question on porting ltmdm and hcfmdm to FreeBSD 8
Hi All, I have a pager monitoring system built on FreeBSD 6.4 that uses the ltmdm driver. (ltmdm is a controllerless winmodem) I was looking into updating to FreeBSD 8 and I see that ltmdm and hcfmdm are now both broken. hcfmdm broke on FreeBSD 7 but it is easily patched to build on that. ltmdm worked on early FreeBSD 8 but after the tty changes went in it broke. I was looking into fixing both of these to build on 8 but it seems to be non-trivial. They both spew all kinds of errors of missing various tty structures, and when I search for those in the include files for 8 I get nothing. It seems there's been a fundamental change in FreeBSD 8 in this layer. In googling around I see that a number of other programs out there that talk to serial ports were also busted by the FreeBSD 8 tty changes. Some have been patched and some not. The ones that have been patched do not seem to have trivial patches made. Setting aside the question of why do we break software that a lot of people use (these chips are in use on a lot of laptops) is there a document somewhere that explains what changes need to be made in code for this new tty setup? Or, is there a set of magic include files or a conversion shim library that will allow these kinds of programs to build without much work? Or is porting these drivers just so non-trivial that the only way is to just delve into the system manuals and delve into the driver code and try to figure out what is going on in each? If that's the case that's probably beyond my ability but I'd be happy to serve as a testbed. Yes I know I can use FreeBSD 7 for now. Yes I know I can use an external modem, and that winmodems are evil, that I can send a page by e-mailing the paging company , yadda yadda yadda. If your only going to suggest a workaround, please don't. Thanks! Ted ___ 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: regenerating /var/db/pkg
On Thu, Apr 22, 2010 at 08:56:39AM -0500, Dan Rue wrote: On Thu, Apr 22, 2010 at 03:21:16PM +0300, Eitan Adler wrote: Just asking opinions, if people want this, I'll make a patch and file a PR. Is this script correct? We're starting to use SSDs for boot drives in our freebsd boxes. We'd like to have /var on a memory backed FS, but losing the package database on every reboot is troublesome. This script would be a decent solution to my problem as well, You can look into how NanoBSD does things if you want to go this route. -- WXS ___ 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
