Re: Order of canonical upgrade sequence
On Wed, 29 May 2013 11:53:41 -0600 Warner Losh i...@bsdimp.com wrote: [[ summarizing a conversation in irc ]] The below fragment doesn't match UPDATING. Since I don't think the order matters; and since we've had no reports that UPDATING is wrong; and since I think way more people follow updating than the Makefile; we should fix the makefile and make the docs match both. The order matters, mergemaster first, then delete-old. UPDATING is correct. At least regarding the order all places should be corrected which tell to use the reverse order. Warner On May 29, 2013, at 10:02 AM, Chris Rees wrote: Hi all! Back in 2005, when Alexander Leidinger wrote the make delete-old target, he documented the order of upgrade such that it should be run before mergemaster [1]; # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' This is the wrong order. I have merged the delete-old section of the Handbook into the upgrading chapter, and independently decided to put mergemaster first, because I thought it would be safer, but checked here before I committed. I think that steps 8 and 9 should be reversed, because of the possibility of an unbootable system being made, when an rc script references an executable that has just been removed for example. I agree. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail?
On Thu, 09 May 2013 15:24:46 -0500 Joshua Isom jri...@gmail.com wrote: If you're just doing virtualization and not worrying about security, I worry about what is going on. We have something which is supposed to provide security as required, but is does not seem to work as described. We either need to fix the documentation, or a bug in the code. To do the later it needs to be debugged. My questions are if this is supposed to work, and if yes how to debug this. Bye, Alexander. there's a simple test. Don't set devfs_enable in rc.conf, and instead add a devfs line to the jail's fstab file. It should give full access to everything in the host's /dev. On 5/9/2013 4:07 AM, Alexander Leidinger wrote: Hi, big picture: I want to get access to my USB DVB device in a jail. First I explain what works (to show what I already know in this regard), then I explain what doesn't work (where I seem to lack some knowledge). What I did so far: I already patched my kernel to give access to /dev/io and /dev/dri in a jail to have X1 up and running in a jail (works since some years): - changed PRIV_DRIVER to PRIV_DRI_DRIVER (new in my kernel) for the priv_check() for /dev/dri - added cases PRIV_IO and PRIV_DRI_DRIVER to sys/kern/kern_jail.c which allow access if a specific allow.xxx flag is set for the jail - added the following lines to devfs.rules in a x11-jail specific section (plus some more devices): ---snip--- add path agpgart unhide add path dri unhide add path 'dri*' unhide add path nvidiactl unhide add path 'nvidia*' unhide add path io unhide add path mem unhide ---snip--- Patches at http://www.Leidinger.net/FreeBSD/current-patches/0_jail.diff Result so far: - I see the io/mem/nvidia* devices (when I had a Radeon card which used /dev/dri, I was also seeing the devices in the /dev/dri/ directory) - I have X11 running in a jail (some config stuff skipped in the above list). My problem: I try now to get the device nodes which are created by multimedia/cuse4bsd-kmod + mltimedia/webcamd visible in a jail, but they only show up in the jail-host, not in the jail itself. I patched the priv_check()s in cuse4bsd-kmod to use PRIV_DRI_DRIVER (because it is already available in my kernel and allowed in the jail where I test this; I expect this is necessary in case I want to run webcamd in the jail instead on the host system) and have the following entries in devfs.rules: ---snip--- [devfsrules_unhide_cuse=13] add path cuse unhide add path video unhide add path 'video*' unhide add path dvb unhide add path 'dvb*' unhide add path input unhide add path 'input*' unhide ---snip--- I also tried with: ---snip--- add path 'dvb/*' unhide add path 'dvb/adapter0/*' unhide ---snip--- (I was as desperate to even reboot the entire host system after changing the rules to make sure I didn't forget to run something which should be run before.) When starting webcamd in the host system (to rule out some other interactions if I would start it in the jail), i can see in the jail: ---snip--- /dev/cuse /dev/dvb/ /dev/input/ /dev/input/event0 ---snip--- In the host system I have additionally: ---snip--- /dev/dvb/adapter0/ca0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/frontend0 ---snip--- I would expect to see at least the /dev/dvb/adapter0, if not all of them in the jail itself. Is there something to the devfs.rules syntax or priv_check() or make_dev()/make_dev_cred() I don't know/understand which is involved when subdirectories of subdirectories in /dev are involved? How can I debug this (where to look, what to look for, ...)? Bye, Alexander. ___ 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 -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail?
On Fri, 10 May 2013 13:43:47 +0200 Uffe Jakobsen u...@uffe.org wrote: On 2013-05-10 12:11, Alexander Leidinger wrote: I worry about what is going on. We have something which is supposed to provide security as required, but is does not seem to work as described. We either need to fix the documentation, or a bug in the code. To do the later it needs to be debugged. It seems to me that you are struggeling with this - or a related - problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 Indeed, this is the problem. I have all entries visible now. Anyone interested to have this changed (as suggested by Andriy in the PR) should voice his opinion. I voiced mine already. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail?
Hi, big picture: I want to get access to my USB DVB device in a jail. First I explain what works (to show what I already know in this regard), then I explain what doesn't work (where I seem to lack some knowledge). What I did so far: I already patched my kernel to give access to /dev/io and /dev/dri in a jail to have X1 up and running in a jail (works since some years): - changed PRIV_DRIVER to PRIV_DRI_DRIVER (new in my kernel) for the priv_check() for /dev/dri - added cases PRIV_IO and PRIV_DRI_DRIVER to sys/kern/kern_jail.c which allow access if a specific allow.xxx flag is set for the jail - added the following lines to devfs.rules in a x11-jail specific section (plus some more devices): ---snip--- add path agpgart unhide add path dri unhide add path 'dri*' unhide add path nvidiactl unhide add path 'nvidia*' unhide add path io unhide add path mem unhide ---snip--- Patches at http://www.Leidinger.net/FreeBSD/current-patches/0_jail.diff Result so far: - I see the io/mem/nvidia* devices (when I had a Radeon card which used /dev/dri, I was also seeing the devices in the /dev/dri/ directory) - I have X11 running in a jail (some config stuff skipped in the above list). My problem: I try now to get the device nodes which are created by multimedia/cuse4bsd-kmod + mltimedia/webcamd visible in a jail, but they only show up in the jail-host, not in the jail itself. I patched the priv_check()s in cuse4bsd-kmod to use PRIV_DRI_DRIVER (because it is already available in my kernel and allowed in the jail where I test this; I expect this is necessary in case I want to run webcamd in the jail instead on the host system) and have the following entries in devfs.rules: ---snip--- [devfsrules_unhide_cuse=13] add path cuse unhide add path video unhide add path 'video*' unhide add path dvb unhide add path 'dvb*' unhide add path input unhide add path 'input*' unhide ---snip--- I also tried with: ---snip--- add path 'dvb/*' unhide add path 'dvb/adapter0/*' unhide ---snip--- (I was as desperate to even reboot the entire host system after changing the rules to make sure I didn't forget to run something which should be run before.) When starting webcamd in the host system (to rule out some other interactions if I would start it in the jail), i can see in the jail: ---snip--- /dev/cuse /dev/dvb/ /dev/input/ /dev/input/event0 ---snip--- In the host system I have additionally: ---snip--- /dev/dvb/adapter0/ca0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/frontend0 ---snip--- I would expect to see at least the /dev/dvb/adapter0, if not all of them in the jail itself. Is there something to the devfs.rules syntax or priv_check() or make_dev()/make_dev_cred() I don't know/understand which is involved when subdirectories of subdirectories in /dev are involved? How can I debug this (where to look, what to look for, ...)? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [CFC/CFT] large changes in the loader(8) code
On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar mar...@xcllnt.net wrote: My advise is to leave disk mirroring to H/W or firmware solutions and use FreeBSD mirroring for FreeBSD partitions only. If you want to mirror the whole disk, don't partition the disk with non-FreeBSD partitioning schemes and partition only with FreeBSD-specific schemes or put a FreeBSD file system on the whole disk. In other words: make the whole disk private to FreeBSD. If I gmirror the entire disk, I already expressed my interest to make the whole disk private to FreeBSD, haven't I? Or are you suggesting to convince all BIOS vendors to include the ability to boot from some kind of FreeBSD private partitioning scheme (not MBR as it is not suitable, not GPT as you are not OK to use it on a gmirror)? Whether or not people agree with this is besides the point. All I'm saying is that unique disk identifiers such as the UniqueMBRSignature (a 4 byte ID written at offset 440 in the MBR) or the DiskGUID (an UUID written to offset 56 in the GPT header) cannot, in general, be mirrored across disks if OSes can see the mirrored disks as independent entities. One violates the spec on grounds of making the *unique* disk identifier non-unique by presenting OSes with multiple disks that have identical IDs. What about multipathing? In case the disk is attached via two paths but multipath is not enabled, the OS sees the same disk (and the same identical unique disk identifier) multiple times. Is this a violation of the spec too? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, 13 Jun 2012 23:06:15 -0700 Garrett Cooper yaneg...@gmail.com wrote: On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). There's a GSoC project underway for this. - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . We have the ideas list for this (http://wiki.freebsd.org/IdeasPage). While it does not attract that much people during the year, it attracts a lot of students which want to participate in the GSoC. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, 13 Jun 2012 22:32:08 -0800 Royce Williams royce.willi...@gmail.com wrote: Even one item from my wish list would lower the branches so that more people could reach the fruit. :-) Well... maybe this year for the crashdump auto-submit part. For the rest I suggest to provide some text suitable for the ideas list (see my other reply). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: CAM disk I/O starvation
On Tue, 3 Apr 2012 14:27:43 -0700 Jerry Toung jryto...@gmail.com wrote: On 4/3/12, Gary Jennejohn gljennj...@googlemail.com wrote: It would be interesting to see your patch. I always run HEAD but maybe I could use it as a base for my own mods/tests. Here is the patch This looks fair if all your disks are working at the same time (e.g. RAID only setup), but if you have a setup where you have multiple disks and only one is doing something, you limit the amount of tags which can be used. No idea what kind of performance impact this would have. What about the case where you have more disks than tags? I also noticed that you do a strncmp for da. What about ada (available in 9 and 10), I would assume it suffers from the same problem. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: DTrace: Where do we run CTFCONVERT for kernel modules
Quoting Shrikanth Kamath shrikant...@gmail.com (from Sun, 26 Feb
2012 13:24:19 +0530):
...meaning, I see the following line in sys/conf/kmod.mk, but that
is a CTFMERGE command.
.if defined(MK_CTF) ${MK_CTF} != no
${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${OBJS}
.endif
Where do we run the CTFCONVERT on kernel modules?
It is run from the Makefile of the kernel which is generated by the
config(8) program.
Bye,
Alexander.
--
Whenever I feel like exercise, I lie down until the feeling passes.
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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?
Quoting Mehmet Erol Sanliturk m.e.sanlit...@gmail.com (from Mon, 20 Feb 2012 11:57:00 -0500): On Mon, Feb 20, 2012 at 9:14 AM, Alexander Leidinger alexan...@leidinger.net wrote: The goal of my work is to produce something like GENERIC+more, just as much as possible loaded as kld's (the +more part is the result of a poll I did on stable@, it contains only stuff which can not be loaded as a kld, and I provide a loader.conf which disables the parts which would cause a major change in behavior). Currently I'm doing some compile testing, I should be able to provide something for review soon (on current@). I think , inclusion of a scheduler ( 4BSD , ULE , etc. ) selection facility into loader.conf will be a useful improvement , because it seems that schedulers are not equivalent . The scheduler as is currently a compile time option and can not be loaded as a module, as such I can not provide such a solution within my current work (= creating a kernel config which loads everything as a module what is available as a module _now_). Bye, Alexander. ___ 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?
Quoting per...@pluto.rain.com (from Sun, 19 Feb 2012 08:13:48 -0800): Doug Barton do...@freebsd.org wrote: 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. Given the context of the thread, this: loading modules through loader.conf is veeryy slooww ... seemed to be an objection to modularizing the kernel. Hence my Looks more like an opinion. In fact, I work on a modularized kernel config which I want to commit to -current at some point (for those which do not care how long it takes to boot the system). The goal of my work is to produce something like GENERIC+more, just as much as possible loaded as kld's (the +more part is the result of a poll I did on stable@, it contains only stuff which can not be loaded as a kld, and I provide a loader.conf which disables the parts which would cause a major change in behavior). Currently I'm doing some compile testing, I should be able to provide something for review soon (on current@). Bye, Alexander. -- WORK: The blessed respite from screaming kids and soap operas for which you actually get paid. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
Hi, I think some tools could help here. If users are able to submit patches to branches they are interested in and some automatic compile/style/whatever testing for them, it would already help. See http://www.leidinger.net/blog/ for a more detailed explanation of this. Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. Adrian Chadd adr...@freebsd.org hat geschrieben:.. and people _do_ realise that this is all mostly driven by volunteers, right? The companies/individuals that _could_ run this kind of thing do it internally. So you're left with volunteers doing the public releases instead of the vendors who are asking for it. Honestly, I think the re@ and ports building teams would _love_ some help. If you'd like to see this happen, step up and offer your assistance. That's the most likely way to achieve your goal. 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 ___ 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
Hi, yesterday I wrote some words in my how we could put the power how long a branch lives a little bit more into he hands of the users. It's available at http://www.leidinger.net/blog/ and also has some sentences how we could improve our knowledge about what bugs our users the most. Maybe it gives some ideas to some people. Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. Matthew D. Fuller fulle...@over-yonder.net hat geschrieben:On Wed, Jan 18, 2012 at 02:20:56PM -0600 I heard the voice of Mark Felder, and lo! it spake thus: On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik j...@kozubik.com wrote: This is nice because no upheaval needs to happen with 7 and 8, and interested developers do not get kneecapped vis a vis 9 - they can just keep going where they were going with it, and the only real change is that 10 is pushed out a long ways, and people[1] get to really sink their teeth into 9. What are the policies for changes though? Are we stuck with 9.0's feature set for 5 years? Will we have to wait 5 years to get a stable release of FreeBSD with KMS/GEM? That work is unfinished and didn't make 9.0; it's also a huge changeset. How will things like this be dealt with? Five years is a long time for the next stable release if we have a policy to not import major changes from -CURRENT. It would be devastating to so many users. This is where the problem comes in. As I read it, John's problem in a sentence is I just got onto 8.x, and it's already shutting down! If the problem is stable trains don't live long enough, why, the solution's simple; make stable trains live longer! The problem is, there are unpleasant tradeoffs every direction we try to go with that. We can: 1) Just make each one live longer. Of course, that means that pretty soon we're maintaining 3 and 4 -STABLE branches all the time. Yeah... maintaining is sure to be an overstatement in that case. Even if we had massively more manpower, the project management complexity would still eat us alive. This is just a non-starter. 2) Wait longer between making new ones. This is what John is suggesting above, but it has two related huge drawbacks. The a) As Mark said, is that it means any significant new features or architectures come out a couple years after they're already obsolete. To pick one example, from 8-9 we have the new eventtimers stuff, which drastically reduces the number of clock interrupts. As we get 4 and 8 and 16 and higher core counts becoming common, that gets very important, as servicing 32k interrupts/second while completely idle is really bad for system efficiency. If we pushed 9 out to 2 years or so from now, we're telling people sure, just eat the overhead until then. Whoops. b) The other big drawback is as I've said in other mails; it turns every major release into a giant watershed of everything changing, which makes upgrading systems across it a *HUGE* amount of work, and *VERY* risky. Again, this had an impact in the 4/5 days; upgrading to 5 was so risky and so different, that lots of people stayed on 4 long after it was out. I sure don't want to deal with that sort of divide again. The more frequent major release steps are, the smaller and easier they are. Now, you could say Well, 2(a) just won't be a problem because we'll merge more stuff back. But now all you're doing is making that -STABLE branch _less_ stable, compromising the reason people are using it in the first place. Now, sure, 'stable' isn't a binary condition, and we can always re-evaluate just where we want to stick the needle. Maybe we could be a bit more aggressive about the size of changes we merge back. But I don't believe that we could get _near_ enough backporting to alleviate the time between the big/dangerous new feature landings, without seriously compromising the stability of -STABLE. Or there's another option, a variant of (1), where we extend the lifetime of some major release trains, but not all. Every second, or every third. Then we can have a longer life, without ballooning out the number of trains being supported. But that has big drawbacks too; the problems of backporting aren't just the number of branches to port too, but how far back they are. Backporting from -CURRENT to 9 right now is almost trivial. Going to 8 isn't too bad for most things. To 7, it's getting to be a much bigger deal. If 7 were an extended support train, with 2 years of active support left on it, not only would backporting things get inordinately expensive from accumulated differences, but they'd get very _risky_ too. They slip from backport into rewrite for, and now we've seriously compromised the stability of the branch, undermining our own goals. Now, I don't suggest the current state is perfect. There are certainly relatively minor tweaks like more common minor
Re: Is there a step by step howto for dtrace on 9.0 ?
On Sun, 9 Oct 2011 20:05:21 +0800 Adrian Chadd adr...@freebsd.org wrote: Hi, the subject says it all - does anyone have a step by step howto for doing userland and kernel dtrace on 9.0? Are you talking about the setup of dtrace? - Wiki Are you talking about how to trace something? - Solaris Dynamic Tracing Guide (for the basics) Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi
Quoting Kurt Lidl l...@pix.net (from Thu, 14 Jul 2011 10:06:45 -0400): On Thu, Jul 14, 2011 at 01:22:49AM -0500, Zhihao Yuan wrote: Second, the perl/tcl interpreter support; you can apply a perl/tcl command to the file whiling you are editing. I beg no one here used this feature before. Bzzt. I've used the perl interpreter before on a project. [description of use-case] Any comments? I don't really care that the perl/tcl integration stays or goes, but it's certainly not never been used. Let's rephrase it: as nvi needs to link to perl, and we do not have a perl in the base since a lng time, surely nobody was using the stock basesystem-nvi with the perl (and tcl) interpreter. As we also will not import perl/tcl into the basesystem again (at least not in the foreseable future), the code is useless for our basesystem. Whoever wants a vi with with such an interpreter, needs to compile one himself anyway and there are enough alternatives in the ports. Bye, Alexander. -- ** MAXIMUM TERMINALS ACTIVE. TRY AGAIN LATER ** http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
X11 in a jail (was: Re: NFS mount inside jail fails)
Quoting Doug Ambrisko ambri...@ambrisko.com (from Wed, 25 May 2011 09:42:20 -0700 (PDT)): CCing jails@ Alexander Leidinger writes: | Quoting Doug Ambrisko ambri...@ambrisko.com (from Thu, 19 May 2011 | 14:38:40 -0700 (PDT)): | | Alexander Leidinger writes: | | On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko | | ambri...@ambrisko.com wrote: | | | | doesn't have access to it anymore either. Running an X server in a | | vimage has some issues. Most are pretty easy to over-come. | | | | Are you using my patch | | (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a | | custom devfs.rules to get the 2D part (the last time I tried the DRI | | part of my patch, it paniced the machine) of the X server working in a | | jail, or did you come up with something yourself? If it is the later, I | | would be interested how you did it. | | Nope, didn't know about it when I played with it. I should try it. | I added | case PRIV_IO: | return (0); | | to kern_jail.c to get X to work. This was with the Intel graphics. | The main problem I have now is on resume the X server dies and restarts. | I use xdm. Without jail with vimage then it works okay. | | I use it without vimage in a jail. This is with a radeon card | (corresponding kernel module loaded at boot to get 2D acceleration, as | the X server obviously can not load modules in a jail). | | My laptop can use either Intel or ATI graphics. I just switched it to | ATI to see what happens. I should try some more tests. It seems | my BIOS likes to reset this setting and enable both :-( | | I don't seem to have panics. This is with a month or so old -current. | | You do not allow access to the dri device, so I do not expect a panic. | If you give access to the dri device (which can be enabled separately | in my patch), I would not be surprised to see a panic (the last time I | tried it is a year or two ago, I didn't take the time to investigate | why it panics). Okay, I have an update. With Intel graphics and using dri things work better and I don't get panics. I load drm.ko i915.ko before Just to make sure we talk about the same things: Did you configure the X server to use 3D (dri and glx in the modules section, dri section in the X11 config, dri device visible in devfs)? xdriinfo shows some valid hardware acceleration? If yes, I definitively have to test the 3D part again with my radeon (with a normal jail and with a vimage jail in case the normal jail fails). starting the vimage jail. X sees it and uses it. This solves the suspend/resume issue I had. The dri issue also prevented suspend and resume fail to work in a chroot. I have not tried switching to using the ATI option. On a plus side my laptop is running cooler and faster now. If you didn't had loaded i915.ko before, you have at least 2D accel now, and probably the power management of the chip got activated too. Bye, Alexander. -- Hope that the day after you die is a nice day. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: NFS mount inside jail fails
Quoting Doug Ambrisko ambri...@ambrisko.com (from Thu, 19 May 2011 14:38:40 -0700 (PDT)): Alexander Leidinger writes: | On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko | ambri...@ambrisko.com wrote: | | doesn't have access to it anymore either. Running an X server in a | vimage has some issues. Most are pretty easy to over-come. | | Are you using my patch | (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a | custom devfs.rules to get the 2D part (the last time I tried the DRI | part of my patch, it paniced the machine) of the X server working in a | jail, or did you come up with something yourself? If it is the later, I | would be interested how you did it. Nope, didn't know about it when I played with it. I should try it. I added case PRIV_IO: return (0); to kern_jail.c to get X to work. This was with the Intel graphics. The main problem I have now is on resume the X server dies and restarts. I use xdm. Without jail with vimage then it works okay. I use it without vimage in a jail. This is with a radeon card (corresponding kernel module loaded at boot to get 2D acceleration, as the X server obviously can not load modules in a jail). My laptop can use either Intel or ATI graphics. I just switched it to ATI to see what happens. I should try some more tests. It seems my BIOS likes to reset this setting and enable both :-( I don't seem to have panics. This is with a month or so old -current. You do not allow access to the dri device, so I do not expect a panic. If you give access to the dri device (which can be enabled separately in my patch), I would not be surprised to see a panic (the last time I tried it is a year or two ago, I didn't take the time to investigate why it panics). Bye, Alexander. -- FORTUNE'S RULES TO LIVE BY: #2 Never goose a wolverine. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: NFS mount inside jail fails
Quoting Arnaud Lacombe lacom...@gmail.com (from Wed, 18 May 2011 22:37:24 -0400): Hi, On Wed, May 18, 2011 at 10:03 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: There are some file systems types that can't be securely mounted within a jail no matter what, like UFS, MSDOFS, EXTFS, XFS, REISERFS, NTFS, etc. because the user mounting it has access to raw storage and can corrupt it in a way that it will panic entire system. This should at least be configurable somehow for people who are using jails for separation and do not care about security. I'd expect that security decision whether or not to allow something is user relevant, not developer relevant. The hardcoded version of this which I use exacly for the purpose you told here is at http://www.leidinger.net/FreeBSD/current-patches/sys:fs.diff Bye, Alexander. -- I think my career is ruined! http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: NFS mount inside jail fails
On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko ambri...@ambrisko.com wrote: doesn't have access to it anymore either. Running an X server in a vimage has some issues. Most are pretty easy to over-come. Are you using my patch (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a custom devfs.rules to get the 2D part (the last time I tried the DRI part of my patch, it paniced the machine) of the X server working in a jail, or did you come up with something yourself? If it is the later, I would be interested how you did it. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: NFS mount inside jail fails
On Tue, 17 May 2011 12:56:40 -0700 Sean Bruno sean...@yahoo-inc.com wrote: Silly thing I ran into today. User wanted to NFS mount a dir inside a jail. After I groaned about the security implication of this, I noted that there is a sysctl that looks like it should allow this. Namely, security.jail.mount_allowed. I noted that setting this follows a path that *should* have allowed this silly thing to happen, except that the credentials in the nfsclient were not setup correctly. As you noticed, this is supposed to allow to mount inside a jail, IF the FS you want to mount is marked as secure/safe to do so. Nearly no FS is marked as such, as nobody wants to guarantee that it is safe (root in a jail should not be able to panic a system by trying to mount a corrupt/malicious FS-image) and secure (not possible to get elevated access/privileges). For NFS there is theoretically the problem that the outgoing address on requests could be the one of the physical host instead of the IP of the jail. If this is true in practice, I do not know. This could be the reason why NFS is not marked with VFCF_JAIL. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [UPDATE] New Boot-Loader Menu -- version 1.4
On Sun, 8 May 2011 13:45:55 -0700 Devin Teske dte...@vicor.com wrote: On May 8, 2011, at 12:13 PM, Alexander Leidinger wrote: On Sun, 8 May 2011 10:48:55 -0700 Devin Teske dte...@vicor.com wrote: I would like to see general consensus from the community for separating the items before moving ahead with such a non-trivial change. IMO: - I agree that there are two different types of actions - having 2 distinct blocks looks like a good idea to me (I didn't had a look at the code, if you only have the text in the variables and the numbers get added automatically, maybe you can add variables for inbetween items which are pure text and do not get a number, and they are not displayed if the variable is empty) - I do not think that we need two different namespaces here - reorder the items, use incrementing numbers no matter which type it is (ACPI would be number 4 in the example then) All-in-all, I love the suggestion. A few notes: - I also agree that there are two different types of actions - Significant changes would need to be made. - I'd like to take the gradual approach - You're right, it could be done without two different namespaces However, there's one very important fact... The current menu is numbers only which means that people that use the menu often will be impacted in a non-trivial way if we re-order the numbers. The gradual approach would have us accept a new menu (such as loader_menu-1.4) that enables the use of hotkeys. Get people used to using the hotkeys for awhile before re-ording (or perhaps even taking-away) the numbers. What do you think of the gradual approach? If you want to spend some years... IMO it's either - change now or - no change, never ever or - change if special variable is set I do not think it is really an option to change it only for new installs but keep the numbers for installed ones as they are (if there is a way to do this). I also think that there will always be some people which never switch to hotkeys. FYI: I never got the numbers into my brain, I always use SPACE to pause and then read which number to press. This could be because I do not (re)boot systems much, but I expect/hope that there are more people which do the same. With the hotkeys this may change, as they are easy to associate with the English word for the action. I'm all for gradual improvements, but there are things which can not be done gradually. This usability improvement is one of the later ones IMO. If nobody complains that such a separation is very hard to get and that it is too hard to press SPACE and that the ordering of the new entries can only be provided by someone with a twisted brain, I would do it, as it looks like very good and better understandable usability improvement which should get new users (to FreeBSD but maybe not to the Unix way) to better get suited with FreeBSD. Maybe an explicit variable to set to go back to the old order if there are too much voices which tell it would violate POLA? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [UPDATE] New Boot-Loader Menu -- version 1.4
On Sun, 8 May 2011 10:48:55 -0700 Devin Teske dte...@vicor.com wrote: I would like to see general consensus from the community for separating the items before moving ahead with such a non-trivial change. IMO: - I agree that there are two different types of actions - having 2 distinct blocks looks like a good idea to me (I didn't had a look at the code, if you only have the text in the variables and the numbers get added automatically, maybe you can add variables for inbetween items which are pure text and do not get a number, and they are not displayed if the variable is empty) - I do not think that we need two different namespaces here - reorder the items, use incrementing numbers no matter which type it is (ACPI would be number 4 in the example then) Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: ZFS pool lost
Quoting Stefan Esser s...@freebsd.org (from Thu, 05 May 2011 13:04:59 +0200): Sorry for the follow-up to my own posting, but I noticed, that I left out significant information. The system is an Athlon64 (X2, but was running with SMP disabled at the time) in 32 bit mode (i386) with 4GB RAM running 8-STABLE in a ZFS only configuration (one UFS partition was mounted but not accessed; it contains an emergency system which allows me to boot the exact kernel and access /rescue in exactly the version that was installed on ZFS). The panic occurs under 8-STABLE/i386 and with identical message when booting a -CURRENT live file-system from CD. The current is from which date? If it is one without zfs v28, please try one with zfs v28 (if you want to have a 8.2-release with v28 patched in: http://mfsbsd.vx.sk/). Maybe the problem is fixed in v28. If the import/export into v28 (it does not updeate the pool automatically, and updating the pool manually is not necessary) and a reimport into v15 does not solve the issue, you could try a import -F on v28 and then export + reimport in v15. Bye, Alexander. -- BOFH excuse #176: vapors from evaporating sticky-note adhesives http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [RELEASE] New Boot-Loader Menu
On Fri, 29 Apr 2011 16:55:12 -0700 Devin Teske dte...@vicor.com wrote: -Original Message- From: Alexander Leidinger [mailto:alexan...@leidinger.net] Sent: Friday, April 29, 2011 1:34 PM To: Devin Teske Cc: 'Mike Meyer'; 'FreeBSD Hackers' Subject: Re: [RELEASE] New Boot-Loader Menu On Fri, 29 Apr 2011 12:02:03 -0700 Devin Teske dte...@vicor.com wrote: I was thinking that what we ought to do is support *both* numbers *and* letters. Sounds good to me. I envision the menuitem numbers remaining unchanged (1-7), allowing those familiar with the numbers to use them. However, as for the letters, I'm thinking that we *BOLD* the mnemonic in the menuitem. For example (showing bolded items between asterisks): 1. Boot *[ENTER]* 2. *A*CPI Support: Enabled 3. Boot Safe Mode: NO 4. Boot *S*ingle User: NO 5. Boot *V*erbose: NO 6. *Esc*ape to loader prompt 7. *R*eboot This should indicate to the user, for example if they see that the V in Verbose is bolded, that they can press that key to activate that menuitem. Your below points are all valid arguments. However, I think they are a bit reaching. The types of people that know what it means to boot into Single-User and/or Verbose mode would not be prone to thinking in those ways. Maybe not single user, but maybe verbose. For me the first question is not how to improve this, my first question is if we need to improve this. I'm still leaning toward just making the V in Verbose and S in Single User bolded. Your initial proposal about the characters looked fine for me. Only making those two in bold looks looks like a step backwards to me. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [RELEASE] New Boot-Loader Menu
On Fri, 29 Apr 2011 12:02:03 -0700 Devin Teske dte...@vicor.com wrote: I was thinking that what we ought to do is support *both* numbers *and* letters. Sounds good to me. I envision the menuitem numbers remaining unchanged (1-7), allowing those familiar with the numbers to use them. However, as for the letters, I'm thinking that we *BOLD* the mnemonic in the menuitem. For example (showing bolded items between asterisks): 1. Boot *[ENTER]* 2. *A*CPI Support: Enabled 3. Boot Safe Mode: NO 4. Boot *S*ingle User: NO 5. Boot *V*erbose: NO 6. *Esc*ape to loader prompt 7. *R*eboot This should indicate to the user, for example if they see that the V in Verbose is bolded, that they can press that key to activate that menuitem. Presented like this a naive first interpretion could be that the letters have to be entered as upper-case. I do not think someone wants to press shift there... Having the characters in bold but the numbers not could also let someone think that only the characters matter. Having a text which tells that the numbers and lower-case characters work for chosing something, may be a solution here. Another solution is maybe 1/[ENTER]. Boot 2/a. ACPI Support... ... but I have to admit that the second solution is ugly. A third solution could be to have the numbers and the characters in bold. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: ask for soc project idea
Quoting husaini harun husaini.insan...@gmail.com (from Tue, 29 Mar 2011 08:45:59 +): example I would like to join existing projects, will have to submit proposal too ? Yes. This is because we want to see if you have a more or less good idea what you can do during the GSoC and if you understand the complexity of the things to do. It also tells what you are interested in to do during thhe GSoC. You do not tell which existing projects, so it could be you talk about things which are huge and can be split into multiple pieces and the proposal is to tell about which piece you want to take care about. Bye, Alexander. -- Aberdeen was so small that when the family with the car went on vacation, the gas station and drive-in theatre had to close. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: ask about Document all sysctls - gsoc 2011
Quoting husaini harun husaini.insan...@gmail.com (from Tue, 29 Mar 2011 09:20:51 +): I am interested to participate Document all sysctls - gsoc 2011 could provide specific to this project, such as how to start a project, in addition, I was FreeBSD 8.2, ZFS users, I have yet to send proposal on freebsd-hackers at freebsd.org This is a pure documentation project, not a coding project. The GSoC is about coding, not about documenting (http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs#documentation). So this project is not suitable for the GSoC. Bye, Alexander. -- Assumption is the mother of all foul-ups. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: E-Mail if updates available?
Quoting Jo Galara jogal...@gmail.com (from Wed, 30 Mar 2011 07:31:27 +0200): Hi, on Debian I'm using apticron which sends me an email if there are updates available for installed packages. Is there a similar program for FreeBSD? If you have portupgrade installed you can change /etc/periodic.conf: ---snip--- weekly_status_pkg_enable=YES pkg_version=/usr/local/sbin/portversion -O pkg_version_index= ---snip--- This will tell you in the weekly mail about ports which could be updated. Bye, Alexander. -- Love thy neighbor, tune thy piano. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Prebind from OpenBSD
Quoting Jesse Smith jessefrgsm...@yahoo.ca (from Sun, 27 Mar 2011 17:29:20 -0300): Thanks very much for the reply. I had thought this was a project/port that was in progress, rather than something waiting on research. Do you know if that's also the case with other projects on the Ideas list? A lot of them don't have many details or contact information associated with them. I'm especially interested in the OpenBSD xlint port. Here's what I told a student who wants to participate in the GSoC about the OpenBSD lint port entry: ---snip--- The project is about having a look at what OpenBSD did to their lint. So first analyze what we have, then analyze what they have, and then see if stuff they have but we haven't can be ported. This assumes that there is a common ancestor to both lints, and that the code didn't diverge too much so that we do not have an either this or that situation. IF the code diverged to much or if there is no common ancestor, there is nothing to do regarding this specific project (it would be a new project to improve our lint). I do not know the code of both lints, so I do not know much improvements there are which we don't have, and how much work it is to port this over. In the worst case there is not enough or too much to do this as a GSoC project. Should be easy to determine by reading the history of lint on both version control systems to see if there is a common starting point, and if yes to see how much they derived from there. Regarding the lint project itself... I (= personal opinion, not an official word from FreeBSD) do not think this is a project which would gain a lot of interest (= highly rated during the GSoC evaluation). If you want to send in a proposal for this (after researching if it is feasible, see above), I suggest to send in more than one proposal. This should improve your change to be chosen. In the last GSoCs we had students which send in several proposals, some of the proposals didn't gain enough interest, but another one from the same person was chosen. Seeing multiple proposals from the same person gave us a hint about his technical knowledge (sane expectations in the proposals or not). ---snip--- Bye, Alexander. -- Snakes. Why did it have to be snakes? http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)?
Hi,
I'm in the process of adding some SDT probes to the linuxulator.
Unfortunately I get a kernel panic while doing a dtrace -l -P
linuxulator. What I see in kgdb puzzles me. Maybe someone can help out?
The id of the provider is 0x0, I would expect this is a little
problem. Debugging session follows with some discussion inline and
afterwards.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x48
fault code = supervisor read, page not present
instruction pointer = 0x20:0x80db03db
stack pointer = 0x28:0xafb4d7f8
frame pointer = 0x28:0xafb4d83c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1415 (initial thread)
trap number = 12
panic: page fault
Uptime: 10m4s
#5 0x8071e9c6 in trap (frame=0xafb4d7b8) at ../../../i386/i386/trap.c:553
#6 0x8070aa4c in calltrap () at ../../../i386/i386/exception.s:168
#7 0x80db03db in dtrace_probe_lookup (prid=0, mod=0xafb4d8e0 emul,
func=0xafb4d8a0 linux_schedtail, name=0xafb4d860 return)
at
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7807
#8 0x80ee0955 in sdt_probe_callback (probe=0x859daca0, arg=0x0)
at /usr/src/sys/modules/dtrace/sdt/../../../cddl/dev/sdt/sdt.c:131
(kgdb) up 7
During symbol reading, Incomplete CFI data; unspecified registers at
0x80560633.
#7 0x80db03db in dtrace_probe_lookup (prid=0x0, mod=0xafb4d8e0
emul, func=0xafb4d8a0 linux_schedtail,
name=0xafb4d860 return)
at
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7807
7807pkey.dtpk_mmatch = mod ? dtrace_match_string :
dtrace_match_nul;
prid is zero...?
(kgdb) list
7802int match;
7803
7804pkey.dtpk_prov = ((dtrace_provider_t *)prid)-dtpv_name;
7805pkey.dtpk_pmatch = dtrace_match_string;
7806pkey.dtpk_mod = mod;
7807pkey.dtpk_mmatch = mod ? dtrace_match_string :
dtrace_match_nul;
7808pkey.dtpk_func = func;
7809pkey.dtpk_fmatch = func ? dtrace_match_string :
dtrace_match_nul;
7810pkey.dtpk_name = name;
7811pkey.dtpk_nmatch = name ? dtrace_match_string :
dtrace_match_nul;
(kgdb) print pkey
$1 = {
dtpk_prov = 0x1e58 Address 0x1e58 out of bounds,
dtpk_pmatch = 0xafb4d83c,
dtpk_mod = 0x80db1143 \213E203034[^_]\220 ,S200d\213\025,
dtpk_mmatch = 0x80ed531c dtrace_lock,
dtpk_func = 0x80dc68d8
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c,
dtpk_fmatch = 0x1e58,
dtpk_name = 0x1e18 Address 0x1e18 out of bounds,
dtpk_nmatch = 0x72e,
dtpk_id = 0x72f
}
(kgdb) print ((dtrace_provider_t *)prid)-dtpv_name
Cannot access memory at address 0x48
Ok, prid is NULL, so this is not a surprise, but why is it NULL?
(kgdb) print prid
$2 = 0x0
(kgdb) print mod
$3 = 0xafb4d8e0 emul
(kgdb) up 1
#8 0x80ee0955 in sdt_probe_callback (probe=0x859daca0, arg=0x0)
at /usr/src/sys/modules/dtrace/sdt/../../../cddl/dev/sdt/sdt.c:131
131 if (dtrace_probe_lookup(prov-id, mod, func, name) != 0)
(kgdb) list
126 */
127 strlcpy(mod, probe-mod, sizeof(mod));
128 strlcpy(func, probe-func, sizeof(func));
129 strlcpy(name, probe-name, sizeof(name));
130
131 if (dtrace_probe_lookup(prov-id, mod, func, name) != 0)
132 return (0);
133
134 (void) dtrace_probe_create(prov-id, probe-mod, probe-func,
135 probe-name, 0, probe);
(kgdb) print prov
$4 = (struct sdt_provider *) 0x859da520
(kgdb) print *prov
$5 = {
name = 0x859d719d linuxulator,
prov_entry = {
tqe_next = 0x0,
tqe_prev = 0x807bbac4
},
probe_list = {
tqh_first = 0x859daca0,
tqh_last = 0x859e442c
},
id = 0x0
}
(kgdb) print probe
$6 = (struct sdt_probe *) 0x859daca0
(kgdb) print *probe
$7 = {
version = 0x34,
state = SDT_INIT,
prov = 0x859da520,
probe_entry = {
tqe_next = 0x859dac40,
tqe_prev = 0x859da52c
},
argtype_list = {
tqh_first = 0x0,
tqh_last = 0x859dacb4
},
mod = 0x859d7204 emul,
func = 0x859d72af linux_schedtail,
name = 0x859d721f return,
id = 0x0,
n_args = 0x0
}
It looks suspicious to mee that the id is NULL. Here is what I do:
kernel with KDTRACE_HOOKS, makeoptions WITH_CTF=yes, DDB_CTF. The SDT
probes are in linux.ko which is loaded after the dtrace, cyclic, sdt,
profile, fbt, systrace and lockstat modules. My patches are at
http://www.Leidinger.net/FreeBSD/current-patches/linuxulator-dtrace.diff
linux_emul.c contains LIN_SDT_PROVIDER_DEFINE(LINUX_DTRACE); which is
just a mapping of SDT_PROVIDE_DEFINE. All other files contain the
corresponding DECLARE.
Actually the kernel crashed at another place which uses
Re: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)?
Quoting Andriy Gapon a...@freebsd.org (from Fri, 25 Mar 2011 12:56:56 +0200): on 25/03/2011 11:52 Alexander Leidinger said the following: As I read it, it looks a little bit like the SYSINIT of the SDT probes didn't work as expected for my new probes (does this work in modules? fxr.watson.org AFAICS only lists SDT probes in kernel-code, not in module-code), a hit with the clue-bat is welcome. My reading of the code is that all modules with SDT proivders/probes should be loaded before sdt module itself. SYSINIT in your module(s) works as expect, but dtrace_register() is not called on your SDT provider. See sys/cddl/dev/sdt/sdt.c for details: sdt_modevent - sdt_load - sdt_provider_listall(sdt_provider_reg_callback) - dtrace_register. So if I load linux.ko before sdt.ko, or if I unload sdt.ko and reload it, it should work? I'm going to try this after sending this mail. I am not saying that this behavior is correct/desired, just that this is what we have now. Is someone working on this? If not, what would be a solution for this? Adding a call (which one) to the modevent of the module which is using SDT probes? Can we prevent a kernel panic for this case (maybe detecting a NULL ID and skipping... or maybe even registering it)? Something to add to the ideas list as a GSoC entry, or is this too small/big? Bye, Alexander. -- One way to make your old car run better is to look up the price of a new model. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: dtrace sdt problem: my fault or a generic problem (SYSINIT not working as expected for modules)?
Quoting Alexander Leidinger alexan...@leidinger.net (from Fri, 25 Mar 2011 14:14:49 +0100): Quoting Andriy Gapon a...@freebsd.org (from Fri, 25 Mar 2011 12:56:56 +0200): on 25/03/2011 11:52 Alexander Leidinger said the following: As I read it, it looks a little bit like the SYSINIT of the SDT probes didn't work as expected for my new probes (does this work in modules? fxr.watson.org AFAICS only lists SDT probes in kernel-code, not in module-code), a hit with the clue-bat is welcome. My reading of the code is that all modules with SDT proivders/probes should be loaded before sdt module itself. SYSINIT in your module(s) works as expect, but dtrace_register() is not called on your SDT provider. See sys/cddl/dev/sdt/sdt.c for details: sdt_modevent - sdt_load - sdt_provider_listall(sdt_provider_reg_callback) - dtrace_register. So if I load linux.ko before sdt.ko, or if I unload sdt.ko and reload it, it should work? I'm going to try this after sending this mail. Unloading sdt.ko was a bad idea... currently I'm waiting the machine recovers from this rude action. It seems there are some modunload checks missing to prevent a kernel panic by unloading sdt.ko when it is not safe. Do we have a place where we can document the current state of afairs, or shall I just add something to the wiki pages (the unload problem to the DTrace page and the load the module with SDT probes before the sdt.ko in the DTrace/HowToAddSDTProbes page)? Bye, Alexander. -- BOFH excuse #378: Operators killed by year 2000 bug bite http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
Quoting Baptiste Daroussin b...@freebsd.org (from Fri, 25 Mar 2011 11:11:11 +0100): pkgng is a binary package manager written from scratch for FreeBSD. I didn't had a look at it, just some comments about some parts you explained. features supported are or will be : - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) This will probably fail if LD_LIBRARY_PATH is used, or if we are installing linuxulator ports. - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture all allows to specify when a package can be used on every architecture. (not done yet) What if a package is able to install on a subset, e.g. the linuxulator ports are for amd64 and i386? In term of technology we decided to use a sqlite3 database, and to prevent potential trolling, sqlite3 is used in it's amalgamation form which means it is incorporated in the code sources (as recommanded by sqlite developpers like a statically linked library) on build we only activate the features we need in sqlite. The alpha release come with an experimental tool pkg2ng to convert an existing package database to the new pkgng database format. So one can test pkgng without rebuild all its packages. What about DB corruption/loss? Do you keep the /var/db/pkg/package/xxx files even with pkgng and only use the DB as a way to speed up some work (so the DB corruption just requires to run pkg2ng), or are you lost of the DB is lost? Bye, Alexander. -- Real computer scientists don't comment their code. The identifiers are so long they can't afford the disk space. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
Quoting Baptiste Daroussin b...@freebsd.org (from Fri, 25 Mar 2011 15:14:52 +0100): 2011/3/25 Alexander Leidinger alexan...@leidinger.net: Quoting Baptiste Daroussin b...@freebsd.org (from Fri, 25 Mar 2011 11:11:11 +0100): pkgng is a binary package manager written from scratch for FreeBSD. I didn't had a look at it, just some comments about some parts you explained. features supported are or will be : - a special architecture all allows to specify when a package can be used on every architecture. (not done yet) What if a package is able to install on a subset, e.g. the linuxulator ports are for amd64 and i386? No clue for that at the moment but we are open to suggestions. The suggestion is easy, allow a way to specify a set of valid architectures. What about DB corruption/loss? Do you keep the /var/db/pkg/package/xxx files even with pkgng and only use the DB as a way to speed up some work (so the DB corruption just requires to run pkg2ng), or are you lost of the DB is lost? Nothing is done about DB corruption/loss, I am not sure we need to do something. Maybe. I would say for sure. Info: In Solaris 10 sqlite is used for the service managenemt framework (SMF). It is possible that the DB is corrupt in some bad situations. In this case you have to rebuild the DB (script provided, been there, had to use it). Currently a filesystem corruption/loss on /var/db/pkg would do the same. Put a corruption of /var/db/pkg/xyz-1/+REQUIRED_BY would only affect a small part, and this part could be even recovered from (pkgdb from portupgrade is able to do it). but it is sqlite so we can perhaps provide a way to get compressed dump so user can periodically backup their database. It needs to be automated. Maybe periodic daily... but maybe this is not often enough after a day of a lot of changes (think about it this way: do you want to lose a day of changes?). The current FS based DB is very robust, partly because there is redundant data, pertly because losing a file just means that the very limited subset of information is lost (and a reinstall of one port will fix it). Bye, Alexander. -- Programming is an unnatural act. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti g...@freebsd.org wrote: On 2011-Mar-25, 15:03, Julien Laffaye wrote: What about DB corruption/loss? Do you keep the /var/db/pkg/package/xxx files even with pkgng and only use the DB as a way to speed up some work (so the DB corruption just requires to run pkg2ng), or are you lost of the DB is lost? Nothing is done about DB corruption/loss, I am not sure we need to do something. Maybe. I would say for sure. Info: In Solaris 10 sqlite is used for the service managenemt framework (SMF). It is possible that the DB is corrupt in some bad situations. In this case you have to rebuild the DB (script provided, been there, had to use it). If sqlite is properly used with transactions, it is very hard to corrupt the database. But if hardware lies to us and say that the And as I told above, I even had such a case (more than once), and the hardware was not buggy. What do you want to tell in this case, life sucks, reinstall everything? data is on disk whereas it isnt... what can we do? Sometimes you have to stay with broken hardware. Another potential problem is fsync(), but if it is broken on FreeBSD we want to fix it! BTW, the goal is to only have the database and not the flat files. If you are paranoid about power outage, use something like zfs snapshots... There are more FS than only ZFS (personally I use ZFS, and I have snapshots, but this is not a good solution for this problem). As I told already, if it isn't automatic, nearly nobody will use it. And the package management stuff has to be automatic, no freshman will think about setting up a snapshot script when he starts to use packages/ports. No need to look for strange scenarios, I'm surely going to sudo rm -f the file more sooner than later, so... maybe just save a copy? A copy or two would be enough, but it has to be done automatically, and once a day is not enough. A copy after each X modifications maybe (for suitable definitions of X and 'modifications'). Bye, Alexander. ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, 25 Mar 2011 13:47:13 -0700 Garrett Cooper yaneg...@gmail.com wrote: On Fri, Mar 25, 2011 at 1:14 PM, Alexander Leidinger alexan...@leidinger.net wrote: On Fri, 25 Mar 2011 16:35:21 +0100 Pietro Cerutti g...@freebsd.org wrote: On 2011-Mar-25, 15:03, Julien Laffaye wrote: What about DB corruption/loss? Do you keep the /var/db/pkg/package/xxx files even with pkgng and only use the DB as a way to speed up some work (so the DB corruption just requires to run pkg2ng), or are you lost of the DB is lost? Nothing is done about DB corruption/loss, I am not sure we need to do something. Maybe. I would say for sure. Info: In Solaris 10 sqlite is used for the service managenemt framework (SMF). It is possible that the DB is corrupt in some bad situations. In this case you have to rebuild the DB (script provided, been there, had to use it). If sqlite is properly used with transactions, it is very hard to corrupt the database. But if hardware lies to us and say that the And as I told above, I even had such a case (more than once), and the hardware was not buggy. What do you want to tell in this case, life sucks, reinstall everything? If you use binary packages, pulling down everything should be trivial, fast, and easy to install. If you're using ports, well then things are going to be slow as expected. And if there is a fast way to cut down the slow part... why not? data is on disk whereas it isnt... what can we do? Sometimes you have to stay with broken hardware. Sometimes you have to go buy new parts? Yes, but if we talk e.g. about aging hardware, having the luck to get hit directly in the parts which hurt is not nice. You want to have the time to find a suitable replacement. Playing with broken hardware is like playing with fire -- sometimes you'll get burned if it goes out of commission during critical operations. I would be more concerned about overall system operation than having a packaging system that can handle all error conditions that should be rightfully handled by various kernel subsystems. If the kernel's doing it's job, then the packaging manager can do its job as well. You know that the world is not an ideal one. Shit happens and Murphy visits you. Another potential problem is fsync(), but if it is broken on FreeBSD we want to fix it! BTW, the goal is to only have the database and not the flat files. If you are paranoid about power outage, use something like zfs snapshots... There are more FS than only ZFS (personally I use ZFS, and I have snapshots, but this is not a good solution for this problem). A lot of filesystems feature snapshot'ing, including UFS. If you aren't smart enough to back up your data you're toast if the data is gone. So... why do we have /var/backups/master.passwd.bak then? To make life easy. I would be more concerned about the program getting killed, not getting properly cleaned up, etc as this is something that the package manager frontend (or whatever the official name is) should catch and fail gracefully with. Things need to follow an ACID methodology and be recoverable in the event that it can't be ACID, or it's no better than pkg_install/ports currently is if it's caught in the middle of a critical operation today installing or removing software. I agree. If SQLite can't deliver this level of ACID-like capability, then pkg_install needs to be redesigned. AFAIK it can. As I told already, if it isn't automatic, nearly nobody will use it. And the package management stuff has to be automatic, no freshman will think about setting up a snapshot script when he starts to use packages/ports. I'd just provide an export command to print out a blah (JSON?) version of the information, and move on. None of the other major packaging systems out there that I know of use flat files for this data, and I would rather not make it automatic because it's an unnecessary performance hit. If the user feels the need for backing up his/her data they will. If not, they're SoL in the event of a crash. - It does not need to be done with every change. - You do not know if it is a performance hit or not, we do not have numbers. - If making an automatic export after X modifications is not expensive, I say: why not? It would make more easy in case of fire. No need to look for strange scenarios, I'm surely going to sudo rm -f the file more sooner than later, so... maybe just save a copy? A copy or two would be enough, but it has to be done automatically, and once a day is not enough. A copy after each X modifications maybe (for suitable definitions of X and 'modifications'). Please see my comment above. There's no reason why this belongs in a packaging system (you can add it as an external tool, but the point is to avoid architectural mistakes that leaked into the old pkg_install over the period of 10
Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
Quoting Robert Watson rwat...@freebsd.org (from Sat, 12 Feb 2011 19:08:59 + (GMT)): On Sat, 12 Feb 2011, Alexander Leidinger wrote: On Sat, 12 Feb 2011 00:52:48 + (GMT) Robert Watson rwat...@freebsd.org wrote: The one comment I'd make is that the MAC case should indicate that The MAC Framework is supported, rather than mandatory access controls being present -- the presence of the framework doesn't imply the presence of mandatory access control policies. Does FEATURE(mac, Mandatory Access Control Framework support); look better? Alternatively/additionally we could use mac_framework as the name of the feature. The above seems fine -- while I've been moving to names like mac_framework.h, it's still options MAC and security/mac, etc, and think that mac is the most consistent options. Committed. If you want you can modify some userland applications to check for it now with feature_present(3). When every feature macro of the GSoC project is committed, I will commit a change to this function (being able to administratively tell a feature is not there when it is there), and a corresponding userland app to be able to use it in scripts. Bye, Alexander. -- One place where you're sure to find the perfect driver is in the back seat. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches)
Quoting Juergen Lock n...@jelal.kn-bremen.de (from Mon, 21 Feb 2011 19:36:11 +0100): And here comes the patch for head: linux_dvb.h is still GPLed (not taking into account that there are voices which tell that interface descriptions are not copyrightable or something like this). As already told this is a no-go, the linuxulator is BSD licensed. Bye, Alexander. Index: src/sys/compat/linux/linux_dvb.h @@ -0,0 +1,63 @@ +/* + * Extracted from linux/dvb/frontend.h, which is: + * + * Copyright (C) 2000 Marcus Metzler mar...@convergence.de + * Ralph Metzler ra...@convergence.de + * Holger Waechtler hol...@convergence.de + * Andre Draszik a...@convergence.de + * for convergence integrated media GmbH + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public License + * as published by the Free Software Foundation; either version 2.1 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + */ Bye, Alexander. -- Sight is a faculty; seeing is an art. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches)
Quoting Juergen Lock n...@jelal.kn-bremen.de (from Tue, 22 Feb 2011 12:37:53 +0100): On Tue, Feb 22, 2011 at 09:26:41AM +0100, Alexander Leidinger wrote: Quoting Juergen Lock n...@jelal.kn-bremen.de (from Mon, 21 Feb 2011 19:36:11 +0100): And here comes the patch for head: linux_dvb.h is still GPLed (not taking into account that there are voices which tell that interface descriptions are not copyrightable or something like this). As already told this is a no-go, the linuxulator is BSD licensed. Right I should have mentioned your concerns. (I said it wouldn't really matter since the linuxolator already is a kld and the header LThe lnuxulator can be included into the kernel (think about an embedded system where the vendor does not want to give the source). The authors of the v4l and v4l2 headers where contacted to get their OK to license the headers within the BSDL (and we got their permission), and I make the suggestion again that you do the same for the dvb header parts you took. If you do not get their OK, my next suggestion is to talk to core about it (if the LGPLed code gets committed without a note that core is OK, I will make a call to core anyway (I will not ask to back it out, it's up to core then to ask for a backout or not), so it may be better to ask before committing). file from which I took the definitions is LGPL'd not GPL'd [1], to which I didn't see an answer.) IMO the first L does not matter if the rest contains GPL. I'm really happy that you take the time to take care about DVB compatibility, and I would like to see the code in FreeBSD, but the linuxulator is (L)GPL free and changing this is a step backward. Bye, Alexander. -- In Newark the laundromats are open 24 hours a day! http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
On Sat, 12 Feb 2011 00:52:48 + (GMT) Robert Watson rwat...@freebsd.org wrote: The one comment I'd make is that the MAC case should indicate that The MAC Framework is supported, rather than mandatory access controls being present -- the presence of the framework doesn't imply the presence of mandatory access control policies. Does FEATURE(mac, Mandatory Access Control Framework support); look better? Alternatively/additionally we could use mac_framework as the name of the feature. Bye, Alexander. ___ 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: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
On Fri, 11 Feb 2011 19:38:06 +0300 Anonymous swel...@gmail.com wrote: Alexander Leidinger alexan...@leidinger.net writes: Hi, during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. [...] Index: kern/kern_dtrace.c [...] +FEATURE(kdtrace_hooks, +Kernel DTrace hooks which are required to load DTrace kernel modules); + [...] Index: kern/kern_lockstat.c [...] +FEATURE(kdtrace_hooks, Kernel DTRACE hooks); Why description differs? Good catch. I removed the second one completely in my working copy. Bye, Alexander. ___ 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
CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
Hi, during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. Here is the list of affected files (for those impatient ones which do not want to look at the attached patch before noticing that they are not interested to look at it): ---snip--- cam/cam.c fs/nfsclient/nfs_clvfsops.c fs/nfsserver/nfs_nfsdport.c kern/kern_dtrace.c kern/kern_ktr.c kern/kern_ktrace.c kern/kern_lock.c kern/kern_lockstat.c kern/kern_ntptime.c kern/kern_pmc.c kern/kern_prot.c kern/ksched.c kern/subr_mchain.c kern/subr_stack.c kern/sysv_msg.c kern/sysv_sem.c kern/sysv_shm.c kern/uipc_cow.c kern/uipc_mqueue.c kern/uipc_sem.c nfsclient/nfs_vfsops.c nfsserver/nfs_serv.c security/audit/audit.c security/mac/mac_syscalls.c ---snip--- Thanks, Alexander. -- Most people in this society who aren't actively mad are, at best, reformed or potential lunatics. -- Susan Sontag http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Index: cam/cam.c === --- cam/cam.c (Revision 218482) +++ cam/cam.c (Arbeitskopie) @@ -51,6 +51,9 @@ #include sys/libkern.h #include cam/cam_queue.h #include cam/cam_xpt.h + +FEATURE(scbus, SCSI devices support); + #endif static int camstatusentrycomp(const void *key, const void *member); Index: fs/nfsclient/nfs_clvfsops.c === --- fs/nfsclient/nfs_clvfsops.c (Revision 218482) +++ fs/nfsclient/nfs_clvfsops.c (Arbeitskopie) @@ -73,6 +73,8 @@ #include fs/nfsclient/nfs.h #include fs/nfsclient/nfsdiskless.h +FEATURE(nfscl, NFSv4 client); + extern int nfscl_ticks; extern struct timeval nfsboottime; extern struct nfsstats newnfsstats; Index: fs/nfsserver/nfs_nfsdport.c === --- fs/nfsserver/nfs_nfsdport.c (Revision 218482) +++ fs/nfsserver/nfs_nfsdport.c (Arbeitskopie) @@ -46,6 +46,8 @@ #include nlm/nlm_prot.h #include nlm/nlm.h +FEATURE(nfsd, NFSv4 server); + extern u_int32_t newnfs_true, newnfs_false, newnfs_xdrneg1; extern int nfsrv_useacl; extern int newnfs_numnfsd; Index: kern/kern_dtrace.c === --- kern/kern_dtrace.c (Revision 218482) +++ kern/kern_dtrace.c (Arbeitskopie) @@ -37,10 +37,14 @@ #include sys/malloc.h #include sys/proc.h #include sys/dtrace_bsd.h +#include sys/sysctl.h #define KDTRACE_PROC_SIZE 64 #define KDTRACE_THREAD_SIZE 256 +FEATURE(kdtrace_hooks, +Kernel DTrace hooks which are required to load DTrace kernel modules); + MALLOC_DEFINE(M_KDTRACE, kdtrace, DTrace hooks); /* Return the DTrace process data size compiled in the kernel hooks. */ Index: kern/kern_ktr.c === --- kern/kern_ktr.c (Revision 218482) +++ kern/kern_ktr.c (Arbeitskopie) @@ -80,6 +80,8 @@ #define KTR_CPU PCPU_GET(cpuid) #endif +FEATURE(ktr, Kernel support for KTR kernel tracing facility); + SYSCTL_NODE(_debug, OID_AUTO, ktr, CTLFLAG_RD, 0, KTR options); int ktr_cpumask = KTR_CPUMASK; Index: kern/kern_ktrace.c === --- kern/kern_ktrace.c (Revision 218482) +++ kern/kern_ktrace.c (Arbeitskopie) @@ -83,6 +83,8 @@ #ifdef KTRACE +FEATURE(ktrace, Kernel support for system-call tracing); + #ifndef KTRACE_REQUEST_POOL #define KTRACE_REQUEST_POOL 100 #endif Index: kern/kern_lock.c === --- kern/kern_lock.c (Revision 218482) +++ kern/kern_lock.c (Arbeitskopie) @@ -1299,6 +1299,10 @@ } #ifdef INVARIANT_SUPPORT + +FEATURE(invariant_support, +Support for modules compiled with INVARIANTS option); + #ifndef INVARIANTS #undef _lockmgr_assert #endif Index: kern/kern_lockstat.c === --- kern/kern_lockstat.c (Revision 218482) +++ kern/kern_lockstat.c (Arbeitskopie) @@ -39,7 +39,10 @@ #include sys/time.h #include sys/types.h #include sys/lockstat.h - +#include sys/param.h +#include sys/sysctl.h +#include sys/kernel.h +FEATURE(kdtrace_hooks, Kernel DTRACE hooks); /* * The following must match the type definition of dtrace_probe. It is * defined this way to avoid having to rely on CDDL code. Index: kern/kern_ntptime.c === --- kern/kern_ntptime.c (Revision 218482) +++ kern/kern_ntptime.c (Arbeitskopie) @@ -51,6 +51,10 @@ #include sys/syscallsubr.h #include sys/sysctl.h +#ifdef PPS_SYNC
Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...
Quoting John Baldwin j...@freebsd.org (from Fri, 11 Feb 2011 07:51:52 -0500): On Friday, February 11, 2011 4:30:28 am Alexander Leidinger wrote: Hi, during the last GSoC various FEATURE macros where added to the system. Before committing them, I would like to get some review (like if macro is in the correct file, and for those FEATURES where the description was not taken from NOTES if the description is OK). If nobody complains, I would like to commit this in 1-2 weeks. If you need more time to review, just tell me. Here is the list of affected files (for those impatient ones which do not want to look at the attached patch before noticing that they are not interested to look at it): Hmm, so what is the rationale for adding FEATURE() macros? Do we just want to add them for everything or do we want to add them on-demand as use cases for each knob arrive? Some features can already be inferred (e.g. if KTR is The non-answer is: IMO we want to add as much as needed. See below for an explanation. compiled in, then the debug.ktr.mask sysctl will exist). Also, in the case of KTR, I'm not sure that any userland programs need to alter their behavior based on whether or not that feature was present. The main goal was to have an easy way (e.g. not a lot of parsing) without sideeffects (e.g. autoloading of kernel modules) to query if a feature is available. Regarding this, there is no need to have one for KTR. The 2nd goal is (as you know, as we discussed it in the beginning of the GSoC) to be able to hide a feature administratively (I plan to commit the userland part regarding this last). You can not do this with sysctl, so for me adding a FEATURE for KTR provides more possibilities. I see a use case for this in KTR, an app may see if it is there and start some tracing based upon it (and it could be adminsitratively prohibited by hiding the presence), or there could be a sanity check in a script which prevents some tracing-setup to happen if it is not there (or administratively hidden). In general I do not want to decide if something makes sense for an app or not, as I do not think I can come up with all possible use cases (possibilities instead of policies). As such it makes sense to add more FEATURE macros to the tree than what we have ATM. If used correctly (via the to be committed userland part), this may make the life of some people more easy. As a 3rd point (attention bikeshed ahead), having everything as a FEATURE would give an uniform way of listing what is available or not (with the benefit to administratively hide parts of it). Needless to say that this would reduce the amount of knowledge and code to determine if something is available (as a person who works in a production environement with mixed knowledge levels of the people and who has to analyse problems which are sometimes caused by lack of knowledge of the people which implemented something, I welcome everything which lowers the learning curve and complexity). Bye, Alexander. -- It wasn't exactly a divorce -- I was traded. -- Tim Conway http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [rfc] Replacing FNV and hash32 with Paul Hsieh's SuperFastHash
Quoting Gleb Kurtsou gleb.kurt...@gmail.com (from Fri, 24 Dec 2010 00:46:20 +0200): Hi, I've recently noticed that hash table use in nullfs was inefficient, 1/3 to half of buckets remained unused. I've started investigating it further and came across SuperFastHash hashing function, SFH (SuperFastHash) has BSD license, used in WebKit and other open source projects. Detailed description and Comparision with FNV and Bob Jenkin's hash can be found here: http://www.azillionmonkeys.com/qed/hash.html I found some web pages which tell about an unfair speed comparision and about a collision problem in SFH: http://coding.derkeiler.com/Archive/General/comp.programming/2005-03/0650.html http://www.team5150.com/~andrew/blog/2007/03/breaking_superfasthash.html http://blog.clawpaws.net/post/2007/04/22/Good-Hash-Functions It may be that this is not an issue for the use case we have here, but blindly replacing it without looking at the above web pages looks a little bit risky to me. Bye, Alexander. -- The use of money is all the advantage there is to having money. -- Benjamin Franklin http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: syscall provider naming convention. Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32
On Sat, 11 Dec 2010 23:38:32 -0800 Artem Belevich fbsdl...@src.cx wrote: Functionally both approaches are about the same functionally. Each has pluses and minuses. Using module, though, looks somewhat cleaner. I agree. Bye, Alexander. ___ 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: syscall provider naming convention. Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32
On Sat, 11 Dec 2010 11:43:05 -0800 Artem Belevich fbsdl...@src.cx wrote: Hi, I'm tinkering with DTrace syscall provider for COMPAT_FREEBSD32 and linuxulator binaries and I wonder what would be the best way to name those providers. Maybe a little bit related: do you know about my (unfortunately out-of-date) branch to add dtrace providers to the linuxulator? http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/ If you are interested feel free to borrow things from there. I'm leaning towards using 'module' but I would appreciate hackers@ opinion on the best way to proceed. My first thought was that this is a good idea. My second thought was the question if you can make the provided values there compatible enough that a dtrace script is able to cope with it when someone does not uses a specific module but the wirldcard operator. If not I suggest to think again about it. Bye, Alexander. ___ 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: [patch] reminding developers to check for duplicates in ObsoleteFiles.inc and tools/build/mk/OptionalObsoleteFiles.inc
Quoting Alexander Best arun...@freebsd.org (from Thu, 18 Nov 2010 18:58:37 +): this change has been discussed on develop...@. Committed (r215669) with a little modification to the description. Bye, Alexander. -- Nature is a mother. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Improve OptionalObsoleteFiles.inc
Quoting Paul B Mahol one...@gmail.com (from Mon, 4 Oct 2010 11:01:45 +):
On 10/4/10, Alexander Leidinger alexan...@leidinger.net wrote:
Quoting Paul B Mahol one...@gmail.com (from Sun, 3 Oct 2010 13:53:26
+):
Hi,
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
b/tools/build/mk/OptionalObsoleteFiles.inc
index d3aa4b2..2123107 100644
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/tools/build/mk/OptionalObsoleteFiles.inc
@@ -141,6 +141,7 @@ OLD_FILES+=usr/share/man/man8/authpf.8.gz
.endif
.if ${MK_BIND} == no
+OLD_FILES+=etc/periodic/daily/470.status-named
If bind is installed from ports instead, this file could be useful, isn't
it?
OLD_FILES+=usr/bin/dig
OLD_FILES+=usr/bin/host
OLD_FILES+=usr/bin/nslookup
[...]
@@ -1976,6 +1998,11 @@ OLD_FILES+=usr/share/man/man8/rtquery.8.gz
.endif
.if ${MK_SENDMAIL} == no
+OLD_FILES+=etc/periodic/daily/150.clean-hoststat
+OLD_FILES+=etc/periodic/daily/210.backup-aliases
+OLD_FILES+=etc/periodic/daily/440.status-mailq
+OLD_FILES+=etc/periodic/daily/460.status-mail-rejects
+OLD_FILES+=etc/periodic/daily/500.queuerun
OLD_FILES+=bin/rmail
OLD_FILES+=usr/bin/vacation
OLD_FILES+=usr/include/libmilter/mfapi.h
At least status-mailq is still useful with other MTAs, e.g. if you use
postfix (and assuming the mailwrapper is configured correctly), this
should still work. Depending on the setup of the aliases,
backup-aliases will still work too. I haven't checked for the other
ones.
If you want to keep some old files, you just need to press `n'
instead of `y'
when deleting files. You are not forced to run make delete-old at all.
I know, I wrote delete-old and related ones. :)
When installing world in new environment such files are not installed anyway.
That's an argument (and your patch is OK). So I should discuss
(somewhere else) if this needs to be changed.
Bye,
Alexander.
--
Stone's Law:
One man's simple is another man's huh?
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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: Improve OptionalObsoleteFiles.inc
Quoting Gonzalo Nemmi gne...@gmail.com (from Tue, 5 Oct 2010 01:30:00 +0200): On Mon, Oct 4, 2010 at 5:31 PM, Paul B Mahol one...@gmail.com wrote: On 10/4/10, Peter Pentchev r...@ringlet.net wrote: On Mon, Oct 04, 2010 at 11:01:45AM +, Paul B Mahol wrote: On 10/4/10, Alexander Leidinger alexan...@leidinger.net wrote: At least status-mailq is still useful with other MTAs, e.g. if you use postfix (and assuming the mailwrapper is configured correctly), this should still work. Depending on the setup of the aliases, backup-aliases will still work too. I haven't checked for the other ones. If you want to keep some old files, you just need to press `n' instead of `y' when deleting files. You are not forced to run make delete-old at all. On the other hand, doing this (skipping those files) on each and every system update (say, on a development or testing machine) could get a bit... boring - not to mention that at some point you'll learn to oh, just say no, and then forget to remove something important. Oh! I see... I want it in black. Hold your horses there ... get it to work as expected and then, _and_only_then_ you can start raising your finger and accussing poster of bikesheding ... As it stands, _it_sucks_ and I have already pointed it out before without much success (something as useless as telnet wasn´t deleted a not so long time ago) ... Peter Pentchev´s point was a completely valid one. As the one who wrote the functionailty: The delete-old stuff is designed to delete stuff which was installed by an installworld (or similar) before, but is not installed by installworld (or similar) now. As there may be old programs around which depend upon such a file or directory, you have to explicitely tell if you are ok to delete it or not (it is the responsability of the administrator to make sure everything is OK). If you are sure no program still depends upon it (make check-old), you can specify -DBATCH_DELETE_OLD_FILES to delete everything without being asked (see man build). As we've read in this thread that the files I would like to keep are not installed by an installworld if the corresponding option is specified, the patch is 100% correct and Peter and you want to use delete-old for something it was not designed for (and I should discuss somewhere else to install the files I talked about even if the corresponding option is specified). Bye, Alexander. -- Detroit is Cleveland without the glitter. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Improve OptionalObsoleteFiles.inc
Quoting rank1see...@gmail.com (from Tue, 05 Oct 2010 14:48:23 +0200): - Original Message - From: Alexander Leidinger alexan...@leidinger.net To: Gonzalo Nemmi gne...@gmail.com Cc: freebsd-hackers@freebsd.org Date: Tue, 05 Oct 2010 11:34:23 +0200 Subject: Re: Improve OptionalObsoleteFiles.inc As the one who wrote the functionailty: The delete-old stuff is designed to delete stuff which was installed by an installworld (or similar) before, but is not installed by installworld (or similar) now. As there may be old programs around which depend upon such a file or directory, you have to explicitely tell if you are ok to delete it or not (it is the responsability of the administrator to make sure everything is OK). If you are sure no program still depends upon it (make check-old), you can specify -DBATCH_DELETE_OLD_FILES to delete everything without being asked (see man build). As we've read in this thread that the files I would like to keep are not installed by an installworld if the corresponding option is specified, the patch is 100% correct and Peter and you want to use delete-old for something it was not designed for (and I should discuss somewhere else to install the files I talked about even if the corresponding option is specified). ~2 months ago I've opened a thread called: Deinstalling parts of base Take a look here: http://forums.freebsd.org/showthread.php?t=17860 We do not have a target which allows to go to src/bin/XXX and run make deinstall or similar. What is correctly written in this thread is that make check-old and make delete-old (and make delete-old-libs) is supposed to do what you want (given that there is already support in the src to exclude this part of FreeBSD during installation). The most up-to-date version is in -current, I do not know about the stable branches (I do not monitor if people which change the corresponding file have merged the changes to stable branches or not). What may not be 100% correct in src is the list of files to delete (= a bug). For this the suggestion in the thread is also correct, if there is something which does not work please send a PR. It would be great if you specify which files are left over or even better provide a patch for the /usr/src/tools/build/mk/OptionalObsoleteFiles.inc file (it's not hard to add files there, you just have to follow the real-world-examples there). Attention: only stuff which is already supported to be skipped during installworld belongs there. So if you specify WITHOUT_XXX and you do an installworld into a scratch-area (with make installworld DESTDIR=/path/to/scratch it shall not show up there). Bye, Alexander. -- Haste makes waste. -- John Heywood http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Improve OptionalObsoleteFiles.inc
Quoting Paul B Mahol one...@gmail.com (from Sun, 3 Oct 2010 13:53:26 +):
Hi,
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
b/tools/build/mk/OptionalObsoleteFiles.inc
index d3aa4b2..2123107 100644
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/tools/build/mk/OptionalObsoleteFiles.inc
@@ -141,6 +141,7 @@ OLD_FILES+=usr/share/man/man8/authpf.8.gz
.endif
.if ${MK_BIND} == no
+OLD_FILES+=etc/periodic/daily/470.status-named
If bind is installed from ports instead, this file could be useful, isn't it?
OLD_FILES+=usr/bin/dig
OLD_FILES+=usr/bin/host
OLD_FILES+=usr/bin/nslookup
[...]
@@ -1976,6 +1998,11 @@ OLD_FILES+=usr/share/man/man8/rtquery.8.gz
.endif
.if ${MK_SENDMAIL} == no
+OLD_FILES+=etc/periodic/daily/150.clean-hoststat
+OLD_FILES+=etc/periodic/daily/210.backup-aliases
+OLD_FILES+=etc/periodic/daily/440.status-mailq
+OLD_FILES+=etc/periodic/daily/460.status-mail-rejects
+OLD_FILES+=etc/periodic/daily/500.queuerun
OLD_FILES+=bin/rmail
OLD_FILES+=usr/bin/vacation
OLD_FILES+=usr/include/libmilter/mfapi.h
At least status-mailq is still useful with other MTAs, e.g. if you use
postfix (and assuming the mailwrapper is configured correctly), this
should still work. Depending on the setup of the aliases,
backup-aliases will still work too. I haven't checked for the other
ones.
In general: please submit via send-pr (or similar) to GNATS. This way
the patch should not be lost.
Bye,
Alexander.
--
There are two ways of disliking art.
One is to dislike it.
The other is to like it rationally.
-- Oscar Wilde
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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: One-shot-oriented event timers management
Quoting Alexander Motin m...@freebsd.org (from Sun, 29 Aug 2010 16:10:00 +0300): I have actively tested this code for a few days on my amd64 Core2Duo laptop and i386 Core-i5 desktop system. With C2/C3 states enabled systems experience only about 100-150 interrupts per second, having HZ set to 1000. These events mostly caused by several event-greedy processes in our tree. I have traced and hacked several most aggressive ones in this patch: http://people.freebsd.org/~mav/tm6292_idle.patch . It allowed me to reduce down to as low as 50 interrupts per system, including IPIs! It looks like you are comming to a point where Powertop would be helpful. There's a dtracified version of it available at the opensolaris site (it would at least need some additional dtrace probes in our kernel). http://hub.opensolaris.org/bin/view/Project+tesla/Powertop Bye, Alexander. -- Our customers' paperwork is profit. Our own paperwork is loss. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: GSoC: registration of optional kernel features via sysctl: a question to the community
Quoting Adrian Chadd adr...@freebsd.org (from Fri, 11 Jun 2010 12:28:58 +0800): How about exposing a simple userspace API for doing this, rather than doing it via sysctl? That way you could simply tie alternative overrides in as needed for builds (eg, environment variables setting overrides; and/or pointing to a configuration file with such) but not affect any runtime detection the rest of the system is doing. There is a framework (ok, one macro: FEATURE()) for the kern.features.X sysctl's. This exposes the features in sysctl when they are there. The goals of the GSoC project are to add more FEATURE()'s to the kernel, and to develop a way to spoof features. A simple way of doing the spoofing part would be some bsd.XXX.mk for ports so that you can maybe set an env-variable to spoof features. This way ports can have a look at it at build-time. This is not an option if you want to know if a feature is there at run-time (spoofing-off a feature just hides the sysctl, it does not disable the feature or prevents the use of it, it is just an administrative way of telling please respect my wish, do not use XXX, and as such we wheren't able to come up with an use for spoof-on). Using an userland program -- maybe featurectl or ftctl or whatever -- does not hide the sysctl's, so any program which decides to use the sysctl's instead, will still see the administratively hidden features. If you want to make features (sysctl) hidden in a jail (not from within the jail but from outside the jail), you have to do something in the kernel anyway, so you do not really need an additional userland program (it's not a problem with sysctl to do it, the question is if spoof-on can only cause harm or not). So far I've seen only responses which I would describe as: - rumors are there are some ports that maybe could use this - I do not have an answer for you, but maybe you could do X Thank you to all such answers, but as this is not some just-for-fun project (Google is paying money to the students for their work), I will tell Ilya to not care about spoof-on, if nobody is showing us a specific example of where spoof-on would make sense (a port where this makes sense would be the best way, an hypotetical example will have to pass a likelyness-analysis and an are-there-good-alternatives-check). As the GSoC is also having a deadline, I will set the deadline for providing such ports/examples to the end of this month. Bye, Alexander. -- You are only young once, but you can stay immature indefinitely. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: GSoC: registration of optional kernel features via sysctl: a question to the community
Quoting jhell jh...@dataix.net (from Wed, 09 Jun 2010 10:54:16 -0400):
That would lead me to believe that the elimination of this sysctl would
be better suited to solve the outcome of cases like this.
And leads me to believe that it still rests on the end-user to tell
whether or not they have that compatibility layer compiled in.
Like I stated more towards the end of my last message I believe
checking __FreeBSD_version should suffice and leave the final result up
to the end-user as GENERIC will have the COMPAT_FREEBSD{N} layers
compiled in that it needs or can support or are recommended.
Being that this is a broad scenario and many different compilations of
kernels could be used I still do not see a need to test for every one of
them if an adequate means already exists. GENERIC in any case should be
the kernel that is depended on and testing against __FreeBSD_version for
what COMPAT versions are supported.
Maybe there is a misconception of what is being done.
We will have something like (out of the top of my head, do not nail me
on the spelling or a particular feature):
kern.features.compat_4
kern.features.compat_6
kern.features.softupdates
kern.features.ufs_snapshots
As soon as something is active in the kernel (directly compiled in or
via a module), the corresponding kern.features.XXX entry will show up
(with a value of 1). The spoofing feature which Ilya was talking about
in this thread will for sure allow to mask an existing feature away.
__FreeBSD_version is not adequate at all for things which require a
feature to be present in the kernel (can be removed in a custom
kernel) and are required at run-time (build-time checks do not help
here, just think about building and installing a program, and then
changing the kernel config and installing a new kernel).
Bye,
Alexander.
--
Don't worry. Clemenza is OK. It's Paulie.
-- Santino Corleone, Chapter 4, page 93
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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: GSoC: registration of optional kernel features via sysctl: a question to the community
Quoting Gary Jennejohn gljennj...@googlemail.com (from Thu, 10 Jun 2010 10:18:01 +0200): On Wed, 9 Jun 2010 10:12:54 -0700 Garrett Cooper yaneurab...@gmail.com wrote: On Jun 9, 2010, at 6:25 AM, Kostik Belousov wrote: On Wed, Jun 09, 2010 at 09:13:56AM -0400, jhell wrote: On 06/09/2010 04:14, Ilya Bakulin wrote: Hi hackers! While discussing my project's implementation details with my mentor, Alexander Leidinger, we've found that one of the ideas needs to be discussed with community, to find out possible use cases. That is, if it should be possible to spoof non-existing features. For example, if currently running kernel doesn't support FreeBSD 5.0 compat layer, kern.features.compat_freebsd5 will be absent when querying features list. The question is -- are there any cases when we want kern.features.compat_freebsd5 be present? If some feature is not in kernel, then presenting its existence to the userland is useless and may be even harmful, if, for example, some application relies on this feature. Or there are some scenarios where such cheat is useful? I can not think of any viable reason why one would want to spoof this when it is not available. Many ports are doing wrong thing there, checking for run-time features at the build-time, turning on/off some functionality depending on its presence on the build host. It's present in the ports Makefiles as well as in many autoconf scripts. It's bad because it causes problems with cross-build and other related scenarios, where you can't assume that the host system is going to match the target system. I don't find one single file in the ports tree which uses kern.features. That's not a surprise, currently there is nothing in kern.features to check for. One of the goals of the GSoC project is to add features to check for. We will have something like (out of the top of my head, do not nail me on the spelling or a particular feature): kern.features.compat_4 kern.features.compat_6 kern.features.softupdates kern.features.ufs_snapshots As soon as something is active in the kernel (directly compiled in or via a module), the corresponding kern.features.XXX entry will show up (with a value of 1). The spoofing feature which Ilya was talking about in this thread will for sure allow to mask an existing feature away. The big question is: where would we need a spoofing feature where a non-existing feature (= no runtime support in the kernel) needs to show up with a value of 1 (let's call this spoof-on)? We identified the following obvious cases: - the software *needs* the feature at build-time - we should not spoof-on a non-existing feature (build error) - the software needs the feature at run-time but not at build-time and the port/configure checks at build-time - the port needs to be changed to test at run-time, spoof-on will hurt and is not needed (the feature is not used yet, so instead of changing the build to check for the feature systl the time is better spend to check at run-time - no need for spoof-on) - the software needs the feature at run-time and checks at run-time - spoof-on will hurt What we search for is a port which does not fall into one of the above cases and where spoof-on does not hurt. Bye, Alexander. -- One man's folly is another man's wife. -- Helen Rowland http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: GSoC: registration of optional kernel features via sysctl: a question to the community
Quoting Kostik Belousov kostik...@gmail.com (from Wed, 9 Jun 2010 16:25:43 +0300): I can not think of any viable reason why one would want to spoof this when it is not available. Many ports are doing wrong thing there, checking for run-time features at the build-time, turning on/off some functionality depending on its presence on the build host. We heard that there are some ports, but we do not know a concrete example. Anyone here with a concrete example of such a port (maybe more than one)? The big question here is: what is going on at build time regarding those features? As you describe the problem, we have to make a change to the port anyway. And IMO it does not matter much if we change it to detect it at run-time (then we do not need the spoofing feature), or if we change it to look for the sysctl at build time. And the preferred way would be to detect at run-time then. What we search for is a good real-life example where spoofing a non-existing feature would be helpful. So far we where able to come up with cases where this would hurt, but not help. Bye, Alexander. -- If the master dies and the disciple grieves, the lives of both have been wasted. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Announcing PathDB
On Sat, 29 May 2010 23:17:40 +0700 C. Bergström cbergst...@pathscale.com wrote: Thordur I Bjornsson wrote: PathScale is slowly open sourcing and porting some of our core software technology and thought the BSD community might be interested in PathDB. Months ago we gave a few FBSD developers You may want to introduce what it is (people which read careful enough may assume it is a debugger) and explain why it is better than the competition. Can someone in the FreeBSD community please talk with this guy. If you're going to send a snotty email at least be brave enough to do it publicly.. He is for sure not one of the FreeBSD committers. Maybe a troll, so it may be better to just ignore him. fwiw.. I never said free anywhere in my email.. It's assumed testing has a reciprocal benefit assuming we fix bugs. I've spoken with 5-10 people in the BSD community and most are supportive of our idea.. They of course wanted the BSD license from the start, but to me this is a conservative approach which I saw as a win/win.. So honestly am I on crack? I don't think your offer to relicense is bad, I just think your introduction of it could have been a little bit more verbose (tell the people something to make them want to have a look at it). Bye, Alexander. ___ 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). It is unlikely that you can help a GSoC student, they shall not rely on the work of other people to be able to finish what they start. I'm no programming expert and have only a basic experience in languages like C, C++, and various scripting languages. My aim for participating in a project with a big organization like The FreeBSD foundation is to understand how programming works in real world projects and use that knowledge to be an active contributor in the open source world. The programming which is done in companies differs from what is done on OSS. Sometimes the OSS way is better (good code quality, good software engineering practices, smart people, ...), sometimes the company way of doing it is better (if it is a good company). Bio: I'm a 3rd year B.Tech (Computer Science) student. I've only basic experience in programming languages like C, C++, Scripting languages. I've absolutely no experience of working on real projects but I'm a fast learner and if given some pointers will try to a valuable resource to the project. I know I'll need to learn a lot and that's why I'm filling out this application because if I'm not selected this year I'll be better prepared for the next year. Additionally, any help provided by the FreeBSD team now (even if it's just a link to a book I've to read) will make me a better candidate for the future. There is no specific pointer to things to read, as there is too much to read and it depends upon what you are interested in. Project Information: I just request to be included in any project which is to be started. I'll read about it as much as I can and will give a description of it and how I can help with it. In the OSS world people to not get included (getting invited), they more attach themself to something (seeing a warm welcome when providing help). We have the FreeBSD ideas list (http://www.freebsd.org/projects/ideas/), the wiki (http://wiki.freebsd.org/) and our bug tracker (http://www.freebsd.org/cgi/query-pr-summary.cgi?category=). I suggest to wait until the GSoC students and their corresponding projects are announced, and then have a look at the remaining ideas, or to have a look at the bug tracker and to try to understand and solve a problem. Try to find out what could be interesting for you and what does not look too hard for you, and then start to research into the topic. You can ask questions on the lists (reading the lists is a good way to get an idea how we work together, and it also gives insight into how things improve over time), if someone knows an answer to your question you will probably get an answer. Bye, Alexander. -- Falling in love is a lot like dying. You never get to do it enough to become good at it. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: leak of the vnodes
Quoting Kostik Belousov kostik...@gmail.com (from Tue, 6 Apr 2010 12:24:29 +0300): Can you try to narrow down the sequence of operations that is needed to reproduce the leak ? As already told privately to kib@ and for the benefit of others reading here: I can reproduce a similar behavior on a recent 9-current by running portsnap extract (/var on UFS, /usr/ports symlink to a ZFS), a traditional kernel build (config KCONFIG, make depend, make on ZFS) or the periodic daily scripts started by cron (UFS and ZFS involved, at least for the daily find(1) run). Bye, Alexander. -- It's more than magnificent -- it's mediocre. -- Sam Goldwyn http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [patch] extending/completing brandelf's OS knowledge
Quoting Doug Barton do...@freebsd.org (from Sun, 24 Jan 2010 21:29:42 -0800 (PST)): On Sat, 23 Jan 2010, Kostik Belousov wrote: I do not see a need for such rudimentary ELF editor in the base at all. So, perhaps it's time to move brandelf out of the base? And if so, perhaps Alexander's contribution could be incorporated into a port for it? Personally I do not see a reason why his work can not go into the base system. From a feature point of view the patch is giving brandelf a little bit more freedom what it is allowed to change. When I look at what I do/did with various tools in FreeBSD which where not intended to be used like this but where useful in some cases, I do not think we should enforce the policy to allow only stuff in brandelf which we are able to emulate. After the work of dchagin@/bz@, brandelf is needed only for the corner cases, if at all. Hmm, I was fooling around with some linux'y stuff the other day and needed to brandelf it (don't remember what, obviously wasn't that important). :) If this happens again in the future, is it worth reporting somewhere? (-emulation@ ?) If it was to brandelf a static linux executable so that the FreeBSD system does not reboot when executing the static linux executable, then I would say it does not need to be reported and we still need brandelf in the base system. If someone says that exactly this case has been fixed recently: it would be great to hear on emulation@ about cases where brandelf is still needed. Bye, Alexander. -- Ferengi Rule of Acquisition #217: You can't free a fish from water. -- ST:DS9, Past Tense, Part I http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: [patch] extending/completing brandelf's OS knowledge
Quoting Kostik Belousov kostik...@gmail.com (from Mon, 25 Jan 2010 11:16:25 +0200): On Mon, Jan 25, 2010 at 10:01:29AM +0100, Alexander Leidinger wrote: If it was to brandelf a static linux executable so that the FreeBSD system does not reboot when executing the static linux executable, then I would say it does not need to be reported and we still need brandelf in the base system. If someone says that exactly this case has been fixed recently: it would be great to hear on emulation@ about cases where brandelf is still needed. If static linux binary contains .note.ABI-tag section, and I believe that relatively modern binaries do, then brand is autodetected. Our linuxulator is not restricted to modern binaries. I remember reports from people which run or try to run binaries (proprietary stuff, all limitations of non-open-source software applies) from linux 2.2 or even older. It's been a while since I've seen such a report, but as it typically just works, I can not tell that we can be sure that nobody wants to run binaries which do not fit your definition of relatively modern. Bye, Alexander. -- No, don't protest. I'm telling you their thoughts, not mine. -- Vito Corleone, Chapter 2, page 74 http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Setting zfs_arc_max value in FreeBSD 8.
On Fri, 22 Jan 2010 21:39:48 -0500 jhell jh...@dataix.net wrote: On Fri, 22 Jan 2010 11:47, fbsdlist@ wrote: Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? You may want to make sure that vm.kmem_size is set to a value much larger than vfs.zfs.arc_max. Default value may be too small to allow such a large ARC. On a side note, I'm not sure that ZFS is a good match for system with only 1G of RAM. By trial and error on my box with 8G or memory I've figured out that I need to set arc_max ~1G below physical memory size to avoid lockups under load. YMMV. ZFS on this box with 1G has been quite enjoyable actually. With the settings I have posted I have not had any lockup on stable/7 and no sudden freezes or waits for transfers. So this entirely thus far has been a godsend. I had even put this thing through some of the tortures that others have posted to the list and not come up with the same results but better. There is obviously a lot of variables in this between hardware and configurations used so the results are minimal in comparison. With ZFS in place on this machine it performs a little bit under specs for the hardware but I wouldn't expect anything less for such a file-system. You may want to switch to fletcher4 checksums. This is the default in Solaris and 8.0 now. I didn't merge this change to 7-stable as I didn't took the time to analyze if the change for the default has some unwanted implications for existig pools. I have a 9-current box with 1GB RAM and ZFS which shows the slow-down after some hours of running (and doing things) too. It would be good to make a list of OS versions and if there are slowdowns or not (anyone with time out there to have a look at the mails and get this info out of the mails / people?). Maybe it is related to changes not in ZFS... Bye, Alexander. ___ 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: Setting zfs_arc_max value in FreeBSD 8.
On Fri, 22 Jan 2010 20:28:09 -0500 jhell jh...@dataix.net wrote: On Wed, 20 Jan 2010 05:14, Alexander@ wrote: Quoting jhell jh...@dataix.net (from Tue, 19 Jan 2010 09:45:58 -0500): On 1/19/2010 5:16 AM, Sherin George wrote: Thanks Ivan :) I found It. add following in /boot/loader.conf === vfs.zfs.arc_max=10244M === I just thought I would give a shout at this for stable/7 as of last week. I am not sure if this is just me but I had tried to adjust zfs_arc_max and found out that it was unadjusted to my value after the system came back up. Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? Can you confirm that you made the modification in /boot/loader.conf, and that you used the double-quotes around the value as shown above? The code in 7-stable regarding this is the same as in 8-stable and 9-current, so if it is done correctly, it has to change accordingly. Yes, The sysctl in question on my machine is/was put in loader.conf with the double quotes. Every time I have set this before I was trying to set it to a value = 512M which with the values below must have not been excepted and fell back to 320M. If I set this to a value of = 511M it works fine which leads me to believe this is limited by some other value listed below ? It can not be bigger than kmem_max. While I do not know if this is checked, it sounds from your description that it is. dmesg: real memory = 1072107520 (1022 MB) avail memory = 1035038720 (987 MB) loader.conf: kern.maxusers=512Not sure if this has anything to do It should influence the kmem_max... if you would not change it yourself. with it. vfs.zfs.arc_min=80M vfs.zfs.arc_max=512M This fails. stays at 335544320. It needs to be a lot less than kmem_max (the arc is allocated from the kmem, as such it can not exceed kmem_max, and as other parts of the kernel also need kmem, you need to limit the arc size). On a 32bit system with 1 GB RAM I have kmem_size_max set to 512M and arc_max set to 160M. vm.kmem_size=512M vm.kmem_size_max=512MMaybe this one. kern.ipc.semmni=40 kern.ipc.semmns=300 kern.maxdsiz=536870912 kern.maxfiles=16384 Bye, Alexander. ___ 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: Setting zfs_arc_max value in FreeBSD 8.
Quoting jhell jh...@dataix.net (from Tue, 19 Jan 2010 09:45:58 -0500): On 1/19/2010 5:16 AM, Sherin George wrote: Thanks Ivan :) I found It. add following in /boot/loader.conf === vfs.zfs.arc_max=10244M === I just thought I would give a shout at this for stable/7 as of last week. I am not sure if this is just me but I had tried to adjust zfs_arc_max and found out that it was unadjusted to my value after the system came back up. Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? Can you confirm that you made the modification in /boot/loader.conf, and that you used the double-quotes around the value as shown above? The code in 7-stable regarding this is the same as in 8-stable and 9-current, so if it is done correctly, it has to change accordingly. Bye, Alexander. -- You ain't learning nothing when you're talking. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: old/unupdated xterm entries in termcap db
Quoting Gary Jennejohn gary.jennej...@freenet.de (from Wed, 9 Dec 2009 12:32:46 +0100): On Wed, 09 Dec 2009 12:29:21 +0100 Dag-Erling Sm__rgrav d...@des.no wrote: Gary Jennejohn gary.jennej...@freenet.de writes: Leonidas Tsampros ltsamp...@upnet.gr writes: Why aren't these entries updated in order to match the ones that ship with xterm? Am I missing something? Probably because xterm is under ports and termcap under src and it would not be easy to track changes in ports under src. The only practical way to keep termcap up to date would be for the committer updating the port to also check and update termcap under src. The problem with this is that most ports committers aren't authorized to make commits under src. That's not an issue - termcaps don't change all that often. We should just import the new definitions. That's a practical attitude, but it begs the question why it hasn't happened in the past. The practical attitude should be coordinated with ed@ (CCed), as he switched the console in 9-current to be an xterm, and AFAIR it does not support as much colors as the real xterm. Maybe there is a reason to not update it. Bye, Alexander. -- You can't depend on the man who made the mess to clean it up. -- Richard Nixon, 1952 http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: UNIX domain sockets on nullfs still broken?
Quoting Julian Elischer jul...@elischer.org (from Wed, 02 Dec 2009 09:43:25 -0800): Alexander Leidinger wrote: Quoting Linda Messerschmidt linda.messerschm...@gmail.com (from Tue, 1 Dec 2009 10:22:02 -0500): On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras ivo...@freebsd.org wrote: What's the sane solution, then, when the only method of communication is unix domain sockets? It is a security problem. I think the long-term solution would be to add a sysctl analogous to security.jail.param.securelevel to handle this. Out of curiosity, why is allowing accessing to a Unix domain socket in a filesystem to which a jail has explicitly been allowed access more or less secure than allowing access to a file or a devfs node in a filesystem to which a jail has explicitly been allowed access? Answer A: There is no difference. Answer B: You open up a direct communication channel between two systems, which may not have been able to communicate before (firewall rules, ...). With files you can do something similar too, but having a socket there makes it more easy and you do not need to write extra code. It is similar to enabling SHM access in jails (currently all jails share the same SHM area). And depending on the application with the socket, you may be able to change files on the other side, to which you do not have access to otherwise (think about a daemon which changes passwords...). I have used chroots and jails in a way that relies on the ability of a shared unix domain pipe being usable to communicate between them, and I also see why it may not be good. What worries me is, that it seems from comments in this thread, that nullfs is having a tighter security regarding jails than UFS/ZFS. I think all should work consistently in this regard (which would mean there will be a regression for some people if we switch UFS/ZFS to work in the same way). I suggest that the ability to do so might be somehow controllable by the jail creator in some way. Answer A is good if you control what is run where and how, and if you use jails for easy data migration and program separation (lightweight virtualization). Answer B is valid if you are an ISP which rents jails (in this case you do not share a FS read-write anyway (at leat you shouldn't) and the point does not really matter). Pick the answer depending on your viewpoint / security requirements and the software you are using. As both points are valid, we should provide the possibility to have both situations working. yes please. A sysctl would do at a pinch, but maybe a per-jail setting might be possible too. Per-Jail is not a problem, I just need to know where the priv check is which is causing this behavior (so far I thought it is some limitation of nullfs and not a priv check). So far I hadn't the time to search for it, I want to finish the import of v4l in the linuxulator first. Bye, Alexander. -- BOFH excuse #102: Power company testing new voltage spike (creation) equipment http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: UNIX domain sockets on nullfs still broken?
Quoting Linda Messerschmidt linda.messerschm...@gmail.com (from Tue, 1 Dec 2009 10:22:02 -0500): On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras ivo...@freebsd.org wrote: What's the sane solution, then, when the only method of communication is unix domain sockets? It is a security problem. I think the long-term solution would be to add a sysctl analogous to security.jail.param.securelevel to handle this. Out of curiosity, why is allowing accessing to a Unix domain socket in a filesystem to which a jail has explicitly been allowed access more or less secure than allowing access to a file or a devfs node in a filesystem to which a jail has explicitly been allowed access? Answer A: There is no difference. Answer B: You open up a direct communication channel between two systems, which may not have been able to communicate before (firewall rules, ...). With files you can do something similar too, but having a socket there makes it more easy and you do not need to write extra code. It is similar to enabling SHM access in jails (currently all jails share the same SHM area). And depending on the application with the socket, you may be able to change files on the other side, to which you do not have access to otherwise (think about a daemon which changes passwords...). Answer A is good if you control what is run where and how, and if you use jails for easy data migration and program separation (lightweight virtualization). Answer B is valid if you are an ISP which rents jails (in this case you do not share a FS read-write anyway (at leat you shouldn't) and the point does not really matter). Pick the answer depending on your viewpoint / security requirements and the software you are using. As both points are valid, we should provide the possibility to have both situations working. Bye, Alexander. -- Is death legally binding? http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: UNIX domain sockets on nullfs still broken?
Quoting Ivan Voras ivo...@freebsd.org (from Mon, 30 Nov 2009
16:14:40 +0100):
xorquew...@googlemail.com wrote:
On 2009-11-30 15:43:01, Ivan Voras wrote:
xorquew...@googlemail.com wrote:
76030 initial thread STRU struct sockaddr { AF_LOCAL,
/tmp/jack-11001/default/jack_0 }
76030 initial thread NAMI /tmp/jack-11001/default/jack_0
76030 initial thread RET connect -1 errno 61 Connection refused
I would expect to see this result from the jail since it's
obviously a Bad Idea, but does it work from the same (host) machine
It is not a bad idea, at least not if we talk about mounting something
from JailA to JailB. Think about the MySQL socket. I have a jail with
MySQL, and I have a jail which wants to connect to it. I do not want
to allow network connections between those jails (be it for
performance reasons, or that I do not want to involve a network
connection, or that I do not want to give the MySQL jail an IP at all
or whatever).
Solution: give access to the socket via the FS. Ideally by putting the
socket in its own directory and mounting this directory over to the
jail. A workaround for this scenario is below.
without the jail in between (i.e. just the nullfs, no jails)?
Hm, yes, you're right. It does work without a jail involved.
What's the sane solution, then, when the only method of communication
is unix domain sockets?
It is a security problem. I think the long-term solution would be to
It is a risk-management problem, and as such not the responsability of
FreeBSD to enforce it. If the sysadmin wants to shoot in his foot, it
is his decision.
add a sysctl analogous to security.jail.param.securelevel to handle this.
Do you know the code which is responsible for the reject of access to
the socket? If yes I can provide a patch regarding jail.param.something.
I don't think there is a workaround right now.
My workaround with MySQL is to have the jail and the socket in the
same FS (I would prefer to have them on separate FS). Then you can do
a hardlink of the socket into the jail (obviously after each restart
of the software, but this can be scripted). This works for me.
Bye,
Alexander.
--
You are capable of planning your future.
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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: Buffer overflow detected by REDZONE with linuxulator
Quoting Alexander Best alexbes...@math.uni-muenster.de (from Wed, 09 Sep 2009 19:01:31 +0200 (CEST)): hi there, CCing emulation@, this is better suited there. Full quote for the benefit of the emulation@ readers. Please drop hackers@ on reply. Thanks. i've installed emulators/linux_dist-gentoo-stage3 and grabbed a snapshot from the ltp git repository (http://ltp.sourceforge.net/). as expected some tests failed because i'm using compat.linux.osrelease: 2.6.16 which is still missing a few linux syscalls, ipcs and ioctls. Are you interested to help update the corresponding FreeBSD wiki page? If yes, register there and we can hand out write access. however i also noticed REDZONE reporting buffer overflows. i'm only a user and not a developer so i don't know if the ltp is to be blamed or if the problem lies within the linuxulator. Probably the later... i'm running 9.0-CURRENT (r196879). as i mentioned before i'm using 2.6 linux kernel emulation. here are the buffer overflow reports: Is your system running in 32bit or 64bit mode? Do you know which ltp-tests cause those messages to appear? Bye, Alexander. Sep 9 14:12:42 otaku kernel: REDZONE: Buffer overflow detected. 9 bytes corrupted after 0xcc28c483 (3 bytes allocated). Sep 9 14:12:42 otaku kernel: Allocation backtrace: Sep 9 14:12:42 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a Sep 9 14:12:42 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 Sep 9 14:12:42 otaku kernel: #2 0xc07428b8 at linux_getsockaddr+0x48 Sep 9 14:12:42 otaku kernel: #3 0xc0742eb8 at linux_socketcall+0x178 Sep 9 14:12:42 otaku kernel: #4 0xc0772f56 at syscall+0x2a6 Sep 9 14:12:42 otaku kernel: #5 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:12:42 otaku kernel: Free backtrace: Sep 9 14:12:42 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a Sep 9 14:12:42 otaku kernel: #1 0xc05bc32d at free+0x5d Sep 9 14:12:42 otaku kernel: #2 0xc0742ef0 at linux_socketcall+0x1b0 Sep 9 14:12:42 otaku kernel: #3 0xc0772f56 at syscall+0x2a6 Sep 9 14:12:42 otaku kernel: #4 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:20:08 otaku kernel: REDZONE: Buffer overflow detected. 4 bytes corrupted after 0xcc2538ea (106 bytes allocated). Sep 9 14:20:08 otaku kernel: Allocation backtrace: Sep 9 14:20:08 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a Sep 9 14:20:08 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 Sep 9 14:20:08 otaku kernel: #2 0xc063a902 at unp_connect+0x162 Sep 9 14:20:08 otaku kernel: #3 0xc063d6c9 at uipc_connect+0x49 Sep 9 14:20:08 otaku kernel: #4 0xc062fde2 at soconnect+0x52 Sep 9 14:20:08 otaku kernel: #5 0xc0638eb6 at kern_connect+0x96 Sep 9 14:20:08 otaku kernel: #6 0xc0742c7b at linux_connect+0x3b Sep 9 14:20:08 otaku kernel: #7 0xc0742f22 at linux_socketcall+0x1e2 Sep 9 14:20:08 otaku kernel: #8 0xc0772f56 at syscall+0x2a6 Sep 9 14:20:08 otaku kernel: #9 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:20:08 otaku kernel: Free backtrace: Sep 9 14:20:08 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a Sep 9 14:20:08 otaku kernel: #1 0xc05bc32d at free+0x5d Sep 9 14:20:08 otaku kernel: #2 0xc063bfb2 at uipc_detach+0x242 Sep 9 14:20:08 otaku kernel: #3 0xc0632a7e at sofree+0x22e Sep 9 14:20:08 otaku kernel: #4 0xc0632f26 at soclose+0x386 Sep 9 14:20:08 otaku kernel: #5 0xc0617c49 at soo_close+0x29 Sep 9 14:20:08 otaku kernel: #6 0xc0598b13 at _fdrop+0x43 Sep 9 14:20:08 otaku kernel: #7 0xc059ab90 at closef+0x290 Sep 9 14:20:08 otaku kernel: #8 0xc059af22 at kern_close+0x102 Sep 9 14:20:08 otaku kernel: #9 0xc059b09a at close+0x1a Sep 9 14:20:08 otaku kernel: #10 0xc0772f56 at syscall+0x2a6 Sep 9 14:20:08 otaku kernel: #11 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:20:09 otaku kernel: REDZONE: Buffer overflow detected. 4 bytes corrupted after 0xccc653ea (106 bytes allocated). Sep 9 14:20:09 otaku kernel: Allocation backtrace: Sep 9 14:20:09 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a Sep 9 14:20:09 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 Sep 9 14:20:09 otaku kernel: #2 0xc063a902 at unp_connect+0x162 Sep 9 14:20:09 otaku kernel: #3 0xc063d6c9 at uipc_connect+0x49 Sep 9 14:20:09 otaku kernel: #4 0xc062fde2 at soconnect+0x52 Sep 9 14:20:09 otaku kernel: #5 0xc0638eb6 at kern_connect+0x96 Sep 9 14:20:09 otaku kernel: #6 0xc0742c7b at linux_connect+0x3b Sep 9 14:20:09 otaku kernel: #7 0xc0742f22 at linux_socketcall+0x1e2 Sep 9 14:20:09 otaku kernel: #8 0xc0772f56 at syscall+0x2a6 Sep 9 14:20:09 otaku kernel: #9 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:20:09 otaku kernel: Free backtrace: Sep 9 14:20:09 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a Sep 9 14:20:09 otaku kernel: #1 0xc05bc32d at free+0x5d Sep 9 14:20:09 otaku kernel: #2 0xc063bfb2 at uipc_detach+0x242 Sep 9 14:20:09 otaku kernel: #3 0xc0632a7e at sofree+0x22e Sep 9 14:20:09 otaku kernel: #4 0xc0632f26 at soclose+0x386 Sep 9 14:20:09 otaku kernel: #5 0xc0617c49 at soo_close+0x29 Sep 9 14:20:09 otaku kernel: #6 0xc0598b13 at
Re: Common interface for sensors/health monitoring
Quoting Antony Mawer li...@mawer.org (from Mon, 24 Aug 2009 10:34:46 +1000): On Mon, Aug 24, 2009 at 2:38 AM, Marc Balmerm...@msys.ch wrote: Is there a summary (perhaps something suitable to go on the Project Ideas page) that outlines: - An outline of what such a system should provide - What it should NOT provide (ie. what would be out of scope) - What lessons should be learned from the SoC effort (ie. both good points and what NOT to do) - Suggested starting points There's nothing like this. The big controversy in the discussion is, that one party wants to put a lot of processing and logic into the kernel (IMO over-engineered), and the GSoC-party wants to keep this complexity out of the kernel (why doing stuff in the kernel when it can be done in the userland, there's no need to get the last few % of performance out of this). Other things discussed there (providing the data via sysctl or via a binary interface in /dev/) are minor implementation details which do not really matter that much (the argument of the GSoC-party was that we already have the sysctl interface and use it already for similar things like process monitoring (kern.proc.*), and it also usable in single-user mode without the need to write another decoding utility for this new binary data). Bye, Alexander. -- Computers are not intelligent. They only think they are. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009 21:02:32 +0200 Aurélien Méré
aurelien.m...@amc-os.com wrote:
I'm just afraid by reading your email that the situation doesn't seem
to have evolved since the discussion regarding the SoC, maybe even
more taboo, and that I'll have to keep writing my own software and
drivers to get the data I want in the future if I want to get this
data under FreeBSD.. Is it the case ?
It is not taboo, it is just that nobody wants to spend his spare time
with something like this now.
And yes, as far as I know you have to keep writting our own stuff. But
maybe we can set up a wiki page where people can share their
FreeBSD specific stuff. Someone just has to be willing to invest some
time to add stuff. I have a little script which adds 24 values to
ganglia, and it's extensible (4 lines for wach value), e.g.:
---snip---
metrics=${metrics} HD3_Temp
HD3_Temp_value=$(smartctl -A ad3 |awk '/Temperature_Celsius/ { print
$10 }') HD3_Temp_type=uint8
HD3_Temp_unit=Celsius
metrics=${metrics} logins
logins_value=$(who -q | grep users | cut -d ' ' -f 4)
logins_type=uint8
logins_unit=Users
metrics=${metrics} SwapIn
SwapIn_value=$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)
SwapIn_type=uint32
SwapIn_unit=Units
---snip---
I would add my script to such a wiki page, if some else is willing to
start such a page.
If someone not @FreeBSD.org wants to maintain such a page, feel free to
register in the wiki and tell me (or another committer), I will hand out
write permission then.
Bye,
Alexander.
___
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: Common interface for sensors/health monitoring
On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer m...@msys.ch wrote:
Am 23.08.2009 um 17:08 schrieb Alexander Leidinger:
On Sat, 22 Aug 2009 21:02:32 +0200 Aurélien Méré
aurelien.m...@amc-os.com wrote:
I'm just afraid by reading your email that the situation doesn't
seem to have evolved since the discussion regarding the SoC, maybe
even more taboo, and that I'll have to keep writing my own
software and drivers to get the data I want in the future if I
want to get this data under FreeBSD.. Is it the case ?
It is not taboo, it is just that nobody wants to spend his spare
time
with something like this now.
And yes, as far as I know you have to keep writting our own stuff.
But maybe we can set up a wiki page where people can share their
FreeBSD specific stuff. Someone just has to be willing to invest
some time to add stuff. I have a little script which adds 24 values
to ganglia, and it's extensible (4 lines for wach value), e.g.:
---snip---
metrics=${metrics} HD3_Temp
HD3_Temp_value=$(smartctl -A ad3 |awk '/Temperature_Celsius/
{ print $10 }') HD3_Temp_type=uint8
HD3_Temp_unit=Celsius
metrics=${metrics} logins
logins_value=$(who -q | grep users | cut -d ' ' -f 4)
logins_type=uint8
logins_unit=Users
metrics=${metrics} SwapIn
SwapIn_value=$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)
SwapIn_type=uint32
SwapIn_unit=Units
---snip---
I would add my script to such a wiki page, if some else is willing
to start such a page.
sarcasm
such a script would indeed be much nicer than a well crafted
framework for the job.
/sarcasm
Indeed...
If someone not @FreeBSD.org wants to maintain such a page, feel
free to
register in the wiki and tell me (or another committer), I will
hand out
write permission then.
I hope people spend their time on thinking what was bad with the
sensor framework last time and improve on that, instead.
Go and read in the archives about it, maybe you understand why
there's not much motivation to spend spare time on such a topic.
Bye,
Alexander.
___
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: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer m...@msys.ch wrote: The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. For smart sensors which trigger an event on their own (interrupt), you can use the exiting kernel event framework (and the idea in the SoC was to use it for such sensors). The devd is the userland side of it. not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... The event stuff is in the kernel, go ahead and write a driver for your smart sensor which fires events on its own. Bye, Alexander. ___ 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: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. Bye, Alexander. ___ 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: DTrace probes klds
Quoting Daniel O'Connor docon...@gsoft.com.au (from Thu, 20 Aug 2009 17:13:07 +0930): On Thu, 20 Aug 2009, Alexander Leidinger wrote: Quoting Daniel O'Connor docon...@gsoft.com.au (from Wed, 19 Aug 2009 23:31:33 +0930): Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Is it possible? the handbook implies not and I can't get it to work, but i could be doing it wrong.. I get fbt traces listed for KLDs (I get new entries for each load of the KLD which seems like a potential problem) but I can't specify an SDT_PROBE and have it work. Can you show us some example code? /* Recycle fbt as SDT_PROVIDER_DEFINE is said not to work */ SDT_PROBE_DEFINE(fbt, gsio, gsio_intr, test); SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 0, int); SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 1, int); I don't think you can define a fbt probe by hand. You can define a provider on your own via SDT_PROVIDER_DEFINE (in only one place/file), and then use this provider instead of fbt above. Let's assume you defined a gsio provider, then the SDT_PROBE_DEFINE could be SDT_PROBE_DEFINE(gsio, unique_part_of_name_of_file, gsio_intr, test); If there's only one file, it does not make much sense to add an unique part of the name of the file, but if you have multiple files it can be helpful. But this is just an example, for example in GEOM it would make sense to name the provider geom, and instead of the file name use the module name, e.g. mirror, raid3, core/whatever, ... instead. Bye, Alexander. -- Fry: Where's Captain Bender? Off catastrophizing some other planet? http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: DTrace probes klds
Quoting Daniel O'Connor docon...@gsoft.com.au (from Wed, 19 Aug 2009 23:31:33 +0930): Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Is it possible? the handbook implies not and I can't get it to work, but i could be doing it wrong.. I get fbt traces listed for KLDs (I get new entries for each load of the KLD which seems like a potential problem) but I can't specify an SDT_PROBE and have it work. Can you show us some example code? In http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/src/sys/compat/linux/linux_emul.c?revision=185383view=markup I have code which worked at least at some point in time when loaded as a KLD. Bye, Alexander. -- A vacuum is a hell of a lot better than some of the stuff that nature replaces it with. -- Tennessee Williams http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Dump Utility cache efficiency analysis
On Tue, 23 Jun 2009 15:52:04 -0400 Nirmal Thacker thacker.nir...@gmail.com wrote: I would also appreciate if I could get simple tips and pointers of setting up my machine for the project. I understand this would be on the lines of: 1. Installing a stable FreeBSD build 2. Check out a version of the Build suitable for the project All development is taking place in -CURRENT, so you would have to check out this one, or you install it right away, it's not declared stable yet, but as we have started the release management process for 8.0, it's not that unstable either... :) 3. Pointers to begin studying the current implementation in the code-tree structure (would I expect it to lie in the fs/ directory?). I tried to find it in the FreeBSD cross reference (http://fxr.watson.org/) 4. Read some important sections of the developer handbook (some suggestions would be great) Dump is a complete userland implementation. All you need to know is the userland programming stuff, specially for what you want to do. You can find it online at http://svnweb.freebsd.org/viewvc/base/head/sbin/dump/ Bye, Alexander. ___ 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: watchdog: hw+sw?
On Fri, 3 Apr 2009 07:19:34 -0700 (PDT) Doug Ambrisko ambri...@ambrisko.com wrote: We start watchdogd manually with our own rc.d script mainly since I noticed Dell pe2650's do false triggers :-( Also I wanted to check that our app. is functioning so we'd need to start after that. It would be good to add flags option to the stock start-up scripts. Just having watchdogd running without checking on anything real tends to be useless since it is usually swapped in and can run just fine without depending on much of the system. In the mean time I noticed that the watchdogd can be started with flags just by adding watchdogd_flags=... to rc.conf. So I just needed to write a shell script which checks the disks which cause problems sometimes, and add a line to rc.conf and now I'm satisfied (... but this should be documented somewhere more obvious). For your app watching stuff, why not write a shell script which checks for a file in a mfs which the app-start creates (if the file is there and the pid not, the app died), and let the WD run this script. This way you can use the default start script. Bye, Alexander. ___ 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: watchdog: hw+sw?
Quoting Doug Ambrisko ambri...@ambrisko.com (from Thu, 2 Apr 2009 16:16:34 -0700 (PDT)): This worked well for us so I think it is a good idea. Also some HW watchdogs can be told to generate an NMI which can also produce a kernel dump/ddb prompt. I've also implemented some rough code to put an simplified back-trace into the IPMI event log in-case a disk or disk I/O sub-system died. Somewhat related... I have 2 32bit systems with zfs which lock up after a while. The lockup is strictly related to the disks. I can still ping the system just fine, and the HW watchdog seems to still work as intended (or it does not work at all anymore, as there's not automatic reset), but as soon as I want to do something which involves disks (access a webpage located on the zfs disks), I'm lost. The only way to get some useful work done again is to reset manually. Your paragraph above implies that the WD notices that there's a problem with disks. While I know how to teach our watchdogd how to detect this (-e option), we do not have support for this in the basesystem yet. Do you have a patch for /etc/rc.d/watchdogd which allows to specify commands to run via rc.conf or some patch which tells watchdogd to check a file? Bye, Alexander. -- Whatever you want to do, you have to do something else first. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Debugging init process.
Quoting Marius Nünnerich mar...@nuenneri.ch (from Wed, 11 Mar 2009 15:54:44 +0100): On Wed, Mar 11, 2009 at 08:51, Alexander Leidinger alexan...@leidinger.net wrote: Quoting Nate Eldredge neldre...@math.ucsd.edu (from Tue, 10 Mar 2009 19:02:16 -0700 (PDT)): On Tue, 10 Mar 2009, vasanth raonaik wrote: Hello Team, I need to debug init process. I am not able to attach init to gdb and it throws As others mentioned, this is explicitly disabled. You could re-enable it by hacking the kernel, but it could cause other unexpected problems. Alternatively, there's always printf debugging. What is wrong with init, that you need to debug it? It's a fairly simple program that's been around for a long time and should be pretty stable. If this is on -current and depending on the problem, dtrace may be an option (I don't know if it special-cases init or not). DTrace is not available for userland processes yet. Depending on what is needed (it may not be needed to attach gdb, it may be sufficient to have something like ktrace, the OP didn't specify the problem), DTrace may suit the needs. Bye, Alexander. -- Your true value depends entirely on what you are compared with. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Debugging init process.
Quoting Nate Eldredge neldre...@math.ucsd.edu (from Tue, 10 Mar 2009 19:02:16 -0700 (PDT)): On Tue, 10 Mar 2009, vasanth raonaik wrote: Hello Team, I need to debug init process. I am not able to attach init to gdb and it throws As others mentioned, this is explicitly disabled. You could re-enable it by hacking the kernel, but it could cause other unexpected problems. Alternatively, there's always printf debugging. What is wrong with init, that you need to debug it? It's a fairly simple program that's been around for a long time and should be pretty stable. If this is on -current and depending on the problem, dtrace may be an option (I don't know if it special-cases init or not). Bye, Alexander. -- Don't interfere with the stranger's style. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: portupgrade spurious skips
Quoting Dan Nelson dnel...@allantgroup.com (from Thu, 26 Feb 2009 23:57:37 -0600): In the last episode (Feb 26), Nate Eldredge said: In the past few months I've noticed a bug in portupgrade. When I update my ports tree and do `portupgrade -a', often a few ports will be skipped, supposedly because another port on which they depend failed to install. However, the apparently failed port actually did not fail, and if I rerun `portupgrade -a', some of the skipped ports will install successfully without complaint. After enough iterations I can eventually get all of them. I'd like to file a PR about this, but it's a little bit tricky coming up with a test case, since the behavior depends on having outdated packages installed, and on the dependencies between them. Moreover, after I run `portupgrade -a' and notice the problem, the state of the installed packages has changed and the same packages aren't skipped the next time. So my question is whether anyone has ideas about how to construct a reasonable test case that could help me make this reproducible and easier to investigate. Any thoughts? me too.. It seems to happen frequently when doing 20 or so ports. Every week or so I upgrade old ports and don't have problems, but after a gnome or xorg update that ends up bumping the portrevision for half my installed ports, it always takes three or four portupgrade -a loops for everything to buid. If you've got ZFS, you can snapshot your filesystems, and if portupgrade fails, roll back to the snapshot and do it again to see if it happens on the same port a second time. Or if you know ruby, you could instrument the code that checks for port build errors and see if it's got a bug in it... There's a more easy solution, pipe the output of portupgrade to a logfile. This way you can have a look what happened with the port which was reported as broken. Maybe there's a dependency missing, and after updating other ports after the failure, this dependency was satisfied so that the next run succeeds. Bye, Alexander. -- A squeegee by any other name wouldn't sound as funny. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Google SoC 2009 Idea
Quoting Siddharth Prakash Singh sps...@gmail.com (from Wed, 25 Feb 2009 07:13:05 +0530): Yeah I sent the same proposal to all the *BSD mailing list, because I am interested in doing this project . What's wrong in proposing the same project in all the *BSD organizations? As one of the FreeBSD mentors for some GSoC's in the past: nothing is wrong with proposing the same project to several *BSD projects, that's not unusual and happened in the past several times. What's not so nice is to propose something without looking at the existing features in this area. It's not just saying I want to do something like this. When you submit your proposal to Google, we expect that you looked at the corresponding code and at least know most of the features. You are not supposed to know each line of code or to understand each line of code, but you should know what is there, and what you need to do until your goal is achieved. For example in one of the past GSoC's proposals told that in the XYZ subsystem A, B and C is missing. They contained a timeframe which explained how much time the student expects until each feature is implemented. For some stuff (API compatibility) even a list of missing functions was presented. You have to understand that in the past we got between 10 and 20 students during the GSoC. For those 10-20 slots there where more than 100 proposals (more in the range of 200-300). Those proposals where filtered by Google, so we've seen only those, which where not immediately rejected by Google because of lack of content. Those proposals have to be rated by the FreeBSD committers which are willing to mentor students, and they do this based upon several checkpoints. We look at the proposal and look if it is actually possible to do what is proposed. Not only in general, also during the timeframe of the GSoC and by a student. It is also not important that all features are completed, so if we think that the student is able to e.g. handle 80% of what he proposes and if we also think that this is ok for us, then we give some points to the proposal. This means that the student has to show that he understands what he is talking about and that he has also some insight into what he has to do and some expectation how long it takes. In the end the proposals with the most points (and someone willing to mentor this project) are taken. So the better the proposal is, more likely it will be that the proposal is accepted. When you look at the FreeBSD ideas page, you see the bare minimum what information needs to be in the proposal (nobody needs to write the required skills in a proposal). When we see a proposal which is just a copy of what we have on the ideas page, it will not get that much points, as it doesn't show if the students really understands what he is proposing. Bye, Alexander. On Wed, Feb 25, 2009 at 1:55 AM, Jordan Gordeev jgord...@dir.bg wrote: Sam Leffler wrote: Siddharth Prakash Singh wrote: On Wed, Feb 25, 2009 at 12:30 AM, Ray Mihm ray.m...@gmail.com wrote: Title: Multicore Aware Process Scheduler. I have not gone through the process scheduler code of Free BSD. Hence, I am not yet aware about the current support for Multicore Architectures. Talk to j...@freebsd.org, the author of ULE. What are your opinions on this project? What is the scope of this project? Linux Kernel 2.6.* currently supports SMP, SMT, NUMA architectures. Does the current scheduler has support for CPU affinity/binding, mechanism for distinguishing varying capability of CPUs. These may be there already in ULE, although I'm not sure about NUMA. Ray Waiting for your response, I note you sent this same note to the netbsd mailing lists. You might want to do some more investigation before you propose a project. Sam It was also sent to the DragonFly mailing lists. :-) ___ 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 -- Siddharth Prakash Singh http://www.spsneo.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 -- There is a certain impertinence in allowing oneself to be burned for an opinion. -- Anatole France http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Mackbook pro nvidia based video backlight
Quoting Ed Schouten e...@80386.nl (from Thu, 29 Jan 2009 15:36:06 +0100): * Alexander Leidinger alexan...@leidinger.net wrote: So you want that either - a daemon running as root is written which listens to user requests to set the backlight via sysctl or - a SUID root program is written that sets the backlight via sysctl instead of - a character device with appropriate filesystem permissions which allows to not go the SUID root or daemon running as root way ? Yes. The primary reason is that it is more consistent with the rest of the operating system. powerd also uses sysctl's instead of a character device, for example. Powerd does not interact with the user, it is doing automatic power management. A backlight on the other hand needs to be adjustable by the user. Normally I would expect some keys on the keyboard to handle this, so there should be no need to have some userland stuff, but as I don't know about how Apple is doing this, I assume there's some valid reason to handle it from userland. But then there needs to be some easy way to let an user handle it, even if you are on the console. A separate daemon or a SUID root program to control the backlight sounds like overkill to me. The ideal solution would be to integrate it into vidcontrol, calling some kind of ioctl on the TTY/consolectl, but syscons is too brainless to know anything about hardware specific features. Here we are back to what was proposed instead of sysctl. I have to admin that I'm confused now about what you propose as a good solution. Bye, Alexander. -- If I had any humility I would be perfect. -- Ted Turner http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Mackbook pro nvidia based video backlight
Quoting Ed Schouten e...@80386.nl (from Wed, 28 Jan 2009 14:43:09 +0100): * Daniel Lannstrom o...@trekdanne.se wrote: I'm asking which method will be the best to interface the driver with userland applications? You might want to make it a character device driver. And write a small userland control program. Sysctl isn't really made for this kind of functionality. No. sysctl is good for doing stuff like this. An even better approach So you want that either - a daemon running as root is written which listens to user requests to set the backlight via sysctl or - a SUID root program is written that sets the backlight via sysctl instead of - a character device with appropriate filesystem permissions which allows to not go the SUID root or daemon running as root way ? Bye, Alexander. -- E.T. GO HOME!!! (And take your Smurfs with you.) http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: bringing ee up to date
Quoting Eitan Adler eitanadlerl...@gmail.com (from Fri, 09 Jan 2009 16:03:49 -0500): I think that these three files bring ee up to date from 1.4.2 to 1.4.6. Sorry, but the patch as is is wrong fore sure. I've seen lp instead of lpr, and even at least one wrong path. For other paths I would have to check to say something definitive. A little bit more work is needed to get an update of this into FreeBSD. How did you proceeded to have a look at the update? Here's how I would do it: 1) diff the version we have with the same version of the vendor + in case of a difference the functionaility needs to be forward ported 2) diff the vendor src of the version of what we have with the next version after it 3) add the differences to our version taking 1) into account and taking care if some path which may be in the new version is OK for us 3.5) if in doubt, ask here, together with a description of what is changed / improved / new 4) repeat from 2) until the most recent version is reached Bye, Alexander. -- LEVERAGE: Even if someone doesn't care what the world thinks about them, they always hope their mother doesn't find out. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: change to ee.c
Quoting Bruce Cran [EMAIL PROTECTED] (from Sun, 30 Nov 2008 10:31:56 -0800): On Sun, 30 Nov 2008 09:12:26 -0500 Eitan Adler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Cran wrote: snip The version of ee in FreeBSD is fairly old: the latest from http://mahon.cwx.net/ is 1.4.6. How difficult would it be to bring it up to date? How come it has not been updated so far? I'd guess it hasn't been updated because it works as it is and nobody has taken an interest in bringing it up to date. I don't know how many patches have been applied locally to it but that would be the main challenge in importing a newer version: you'd have to go through the FreeBSD CVS history and check that any changes/fixes that were made to FreeBSD's version are either already included in the new release or ensure that those changes get re-applied to the new version. It _may_ be more easy to find out which version is in our source tree, and make a diff between the original vendor version and what we have. Depending on the amount of changes there, this is faster than to real all the version control logs to determine if there's a difference or not. In the end you have to read some logs too, but only those, which change lines which a different from those of the vendor version (e.g. via the annotated view at cvsweb.freebsd.org). Bye, Alexander. -- In this vale Of toil and sin Your head grows bald But not your chin. -- Burma Shave http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New C compiler and analyzer lang/cparser in ports
Quoting Christoph Mallon [EMAIL PROTECTED] (from Thu, 27 Nov 2008 21:39:45 +0100): cparser is a C compiler, which can parse C89 and C99 as well as many GCC and some MSVC extensions. The handled GCC extensions include __attribute__, inline assembler, computed goto and statement expressions. The compiler driver is compatible with with GCC (-fxxx, -Wxxx, -M, ...). It also provides many useful analyses for warnings - for some examples see below. How much of the GCC stuff in /usr/include/cdefs.h would work with cparser? Info: this is the major part one has to do to make another compiler ready to compile our kernel. Bye, Alexander. -- What this country needs is a good five-cent nickel. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
HOWTO in wiki: adding custom dtrace probes in the kernel
Hi, while working on adding dtrace probes to the linuxulator, I thought it may be interesting for some people to know how to do this, so I added some text/examples into the wiki how to add static dtrace probes in the kernel: http://wiki.freebsd.org/HOWTO-dtrace-sdt If you are interested in the great debugging possibilities of dtrace, don't be afraid to add some probes to the kernel. It's cheap and easy. Bye, Alexander. -- Leela: You buy one pound of underwear and you're on their list forever. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for individuals interested in reviewing test / python topics
Quoting Garrett Cooper [EMAIL PROTECTED] (from Sat, 15 Nov 2008 14:08:02 -0800): Hello Hackers and Porters, I'm currently working on a proposal to the FreeBSD foundation to use Python Nose as a testing framework for writing tests. If there are Are you aware of the history of the current regression tests? If not: It started without a structure, then some work was done to move to the perl testing framework style (really only the output of the tests, and the naming conventions in the directory). This was not completed, and newer tests may not comply. The reason for chosing the perl style was, to be able to use the extensive perl tools to - automatically run all the tests - be able to compare different runs with the perl tools - be able to generate a lot of different output formats (html/text/...) There's also a wiki page about testing, which you may want to check out: http://wiki.freebsd.org/TetIntegration I don't really know python nose. I just looked at it quickly and can not see any big benefit compared to the perl test protocol outlined above (and the stuff outlined in the wiki looks even more advanced than that). Would you please elaborate where you see the benefits of it? Note that during release building perl is needed anyway to generate the index for the ports collection. I don't know if python is required currently during the release generation. Bye, Alexander. -- I would have made a good pope. -- Richard Nixon http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RTLD changes for non-native system (was: Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit ?binaries?)
Quoting Daniel O'Connor [EMAIL PROTECTED] (from Tue, 28 Oct 2008 10:18:10 +1030): On Tuesday 28 October 2008 01:31:16 M. Warner Losh wrote: In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : Daniel O'Connor wrote: : On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: : this will make system trying to bind 32-bit libs to 64-bit : program. it can't work : :rtld shouldn't attempt to bind 32-bit libs to 64-bit programs. : : The same problem happens with the Linux run time linker - it merrily : tries to link FreeBSD libraries to Linux binaries with predictable : results.. : : You *can* link Linux libraries with FreeBSD binaries (and : vice versa), if the library does not perform any syscalls, : e.g. it is a pure computation library or similar. : : That said it would be really nice if it ignored incompatible libraries : :) : : No. Please don't put such pseudo-cleverness into rtld. : It wouldn't be an improvement, in fact it might break some : working configurations. Yes. I have a bunch of printer drivers that I've used that link in linux shared libraries... They are in ports... Good point.. The problem is really the Linux linker - it will find a FreeBSD library and try and use it ahead of a Linux one later in the search path - this prevents stuff working :) I have this exact problem with libfontconfig and Xilinx ISE. Perhaps instead of ignore, use last.. But then it doesn't really matter for the FreeBSD linker - I imagine I would have to convince Linux folks it's a good idea. Please ignore for a moment that we are not talking about changing the FreeBSD RTLD anymore: Would it make sense (for us and/or for GNU) to first search for libs for the current system and if none are found to try the others? Bye, Alexander. -- There is hardly a thing in the world that some man can not make a little worse and sell a little cheaper. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Hardware support for AMD Geode CS5536 audio?
Quoting [EMAIL PROTECTED] (from Thu, 2 Oct 2008 05:05:12 -0400): To All, I finally have a working CS5536 audio driver for FreeBSD 6.2. The filename is snd_amd5536.ko and I will be making it available shortly. I have been using an ALIX-1C motherboard for my testing. Anyone have other hardware that they want to test it on? Another question. How does one get the FreeBSD people to put this driver into their OS? You have to generate a patch for 8-current and send it to [EMAIL PROTECTED] for review. There may be some improvement suggestions or bug reports then. Fix the issues and generate a new patch. When there are no issues anymore, send a PR (problem report) with your patch. If you are lucky, a committer will take care of the PR (or he may already approach you before you send the PR). Bye, Alexander. -- It has long been an axiom of mine that the little things are infinitely the most important. -- Sir Arthur Conan Doyle, A Case of Identity http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Video class
Quoting Peter B [EMAIL PROTECTED] (from Tue, 19 Aug 2008 15:05:29 +0200 (MEST)): Is there any ongoing project towards USB Video class support in FreeBSD ..? This is better asked on usb@ (CCed). I'm not aware of such an effort, feel free to start it (you better wait some days until the new USB stack hits CVS). Bye, Alexander. (Looking at the Asus eee builtin webcam 0x04F2 (CHICONY) 0xB071) Some links: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/ uvideo.c http://developer.berlios.de/projects/linux-uvc http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1.zip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- While you don't greatly need the outside world, it's still very reassuring to know that it's still there. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
Quoting Nate Eldredge [EMAIL PROTECTED] (from Tue, 12 Aug 2008 23:52:35 -0700 (PDT)): Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. A guess out of my cristallball: That's one of the cases which happen if you run a linux program without branding it as a linux program first. People tend to think it is not needed, but in some rare circumstances it just causes what you see, a reboot. So go and identify all binaries (IMPORTANT: but not the libraries!), e.g. with the file(1), and use brandelf -t Linux on those programs. Bye, Alexander. -- She said, I know you ... you cannot sing. I said, That's nothing, you should hear me play piano. -- Morrisey http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea for FreeBSD
Quoting Kurt J. Lidl [EMAIL PROTECTED] (from Thu, 7 Aug 2008 16:20:42 -0400): On Thu, Aug 07, 2008 at 07:02:30PM +1000, Peter Jeremy wrote: On 2008-Aug-06 19:14:51 -0400, [EMAIL PROTECTED] wrote: In Solaris 10 the Services Management Facility (SMF) was introduced. The main purpose of SMF appears to be to drum up business for Sun's training courses by radically changing Sol10 Administration for little benefit. The main purpose of SMF was to make it possible to programmatically control the system and deal with the myriad of different types of faults from the gazillion different things that people want to run on machines. It's complex because it has to deal with the real world. There's also some sort of functionality included, which is comparable with daemontools (depending if you enable this in the xml description or not). You could say this is included in your deal with ... faults above, but for people not aware of this it may be nice to know. Bye, Alexander. -- Life may have no meaning, or, even worse, it may have a meaning of which you disapprove. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 14:54:13 +0300): On Wed, Aug 13, 2008 at 01:28:22PM +0200, Alexander Leidinger wrote: Quoting Nate Eldredge [EMAIL PROTECTED] (from Tue, 12 Aug 2008 23:52:35 -0700 (PDT)): Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. A guess out of my cristallball: That's one of the cases which happen if you run a linux program without branding it as a linux program first. People tend to think it is not needed, but in some rare circumstances it just causes what you see, a reboot. So go and identify all binaries (IMPORTANT: but not the libraries!), e.g. with the file(1), and use brandelf -t Linux on those programs. That would be an enormous local hole, assuming an native FreeBSD binary may cause system crash. I actually doubt that non-branded elf binary ever start, due to unsatisfied dynamic dependencies. You see this behavior only for static binaries. In the non-branded case the image activator takes the FreeBSD image and unfortunately there's a common syscall in linux which matches the syscall number in FreeBSD which causes the reboot (IIRC reboot syscall, do we have something like this?). It's not a system crash (kernel panic), it's a real reboot. AFAIR this also only works if you run the program as root. So... Bye, Alexander. -- Blow it out your ear. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 17:10:59 +0300): On Wed, Aug 13, 2008 at 04:03:53PM +0200, Alexander Leidinger wrote: Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 14:54:13 +0300): On Wed, Aug 13, 2008 at 01:28:22PM +0200, Alexander Leidinger wrote: Quoting Nate Eldredge [EMAIL PROTECTED] (from Tue, 12 Aug 2008 23:52:35 -0700 (PDT)): Hi folks, I recently tried to run a Linux binary of Maple (commercial math software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine rebooted. I tried it again while watching the console, and no panic message appeared to be produced. Does anyone have any ideas on how to debug problems of this nature? I realize I may not be able to get Maple to work, but in any case the system should not die like this, so I can at least try to fix that bug. Incidentally, is it possible to run kdb with a USB keyboard? Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I can do nothing except hit the power button. I do have hint.atkbd.0.flags=0x1 in /boot/device.hints. Unfortunately I don't have a PS/2 keyboard on hand, though I can try and get a hold of one if all else fails. A guess out of my cristallball: That's one of the cases which happen if you run a linux program without branding it as a linux program first. People tend to think it is not needed, but in some rare circumstances it just causes what you see, a reboot. So go and identify all binaries (IMPORTANT: but not the libraries!), e.g. with the file(1), and use brandelf -t Linux on those programs. That would be an enormous local hole, assuming an native FreeBSD binary may cause system crash. I actually doubt that non-branded elf binary ever start, due to unsatisfied dynamic dependencies. You see this behavior only for static binaries. In the non-branded case the image activator takes the FreeBSD image and unfortunately there's a common syscall in linux which matches the syscall number in FreeBSD which causes the reboot (IIRC reboot syscall, do we have something like this?). It's not a system crash (kernel panic), it's a real reboot. AFAIR this also only works if you run the program as root. So... Then, the issue of mixing our reboot(2)/linux fcntl(2) is irrelevant. The original reporter said that system just rebooted, and I believe that filesystems where not synced and not unmounted properly. Our reboot(2) does not have flag combination that could cause such behaviour, I think. Also, I doubt that the program being run is statically linked or run by root. Confirmation ? I will not be surprised if it is statically linked and run by root. I've seen enough such cases with commercial software and users using it, that my cristalball caused me to send my first reply to the problem. Overall, this looks like a nasty bug, hopefully in the linuxolator. The linuxulator is not involved, as there's no branding it is not invoked. The same will happen if the linxulator is not in the kernel. Bye, Alexander. -- If value corrupts then absolute value corrupts absolutely. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging reboot with Linux emulation
Quoting Kostik Belousov [EMAIL PROTECTED] (from Wed, 13 Aug 2008 18:45:01 +0300): On Wed, Aug 13, 2008 at 05:28:05PM +0200, Alexander Leidinger wrote: The linuxulator is not involved, as there's no branding it is not invoked. The same will happen if the linxulator is not in the kernel. Ok, if the case is confirmed, I very much want to get such binary into my hands. I.e., unbranded statically linked ELF binary running which causes immediate reboot without normal kernel shutdown sequence. You could try /compat/linux/sbin/ldconfig without a brand. If it uses fcntl, it should trigger the problem. Bye, Alexander. -- Some people have no respect for age unless it's bottled. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TET and other testing framework for FreeBSD
Quoting Garrett Cooper [EMAIL PROTECTED] (from Mon, 21 Jul 2008 23:43:11 -0700): Hi Joseph (and hackers), I'm contacting Joseph primarily because I saw his name listed under the TET page (http://wiki.freebsd.org/TetIntegration) as a contact and was wondering whether or not there was any interest to integrate test suites outside of TET into FreeBSD, but I'm also involving hackers@ because there might be some references that someone can provide me for other @freebsd folks. AFAIK there's no TET stuff for FreeBSD available in public. So I would say it's more having regression tests available (making them compile and run on FreeBSD, having a look at the failing tests and see if it is a problem with the test or with FreeBSD ... see below for my experience with the LTP) at all, than integrating them. I ask because my work with LTP (Linux Test Project : http://ltp.sf.net) for Cisco has allowed me some insight into using OpenPOSIX and Ballista testing frameworks, which may prove helpful in the release testing cause, and could help in detecting faults earlier on, thus helping expedite the release process a bit more and increasing confidence and interest in FreeBSD. Do you have any URLs or whatever besides the LTP one (where those are integrated) to get those tests from an official point instead from cutting it out of the LTP? I'm pretty sure I have the blessings of the Ballista project's principal investigator to relicense it under the BSD / GPL license, it's currently a 'dead project' and he gave his blessings to post the source up on Sourceforge, but I'll double check to make sure I have his AOK before doing so... I think it would be beneficial so the what this produces on FreeBSD (the license doesn't matter here) before we go and talk about integration (here the license matters). I'm also working on getting tst_res (1.) dually licensed from the LTP folks with a BSD / GPL license to allow for better inclusion into FreeBSD's infrastructure, to ensure that we have a deterministic means of dealing with testcases and reporting. Just wondering what, if any, interest would be in adopting and applying this work to FreeBSD for the good of the community. If this is what is used in the LTP to run some tests, I have to say it does not look mature. I've run the LTP a lot in FreeBSD (native linux binaries, http://wiki.FreeBSD.org/linux-kernel/ltp ... LTP not run and updated the page since a long time) to test the linux compatibility layer, and the are several places where tests fail and no output is produced or even the summary said the test passed. I even opened bug reports at the LTP page on SF, but it seems nobody was interested in those reports. There are also some other ideas, like using the protocol the perl test suites use, to be able to use existing perl stuff to generate reports and overviews out of the generated logs (AFAIR this was the idea behind some changes to the existing regression tests a long time ago). Bye, Alexander. -- I read Playboy for the same reason I read National Geographic. To see the sights I'm never going to visit. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel API docs ('make doxygen')
Quoting Mel [EMAIL PROTECTED] (from Fri, 11 Jul 2008 15:17:54 +0200): I was wondering if this project is considered obsolete, finished or work in progress. I would say it's in the it has to prove it's usefulness-stage. This means not all people are convinced it is useful to have such stuff in our source and someone needs to sit down and do something good to a subsystem to show that it is useful to those people. If it's the latter, I'm happy to do the legwork, like set up proper stubs for each function and structure that people who really know how they work can I think some people would complain if this would be committed to our version control system without consent, and without those stubs being there I don't expect that the stubs get converted to proper docs. So giving advice to just go ahead may be a waste. adjust. There's a lot already in there with normal comments, that can become documentation by simply adding an extra asterisk. Decide for yourself if you are willing to invest your time to convert the existing docs in the source into doxygen docs. In src/tools/kerneldoc/subsys/ is already a framework to handle the doxygen stuff per subsystem (not all subsystems are done there). It would be most beneficial to start with one of the subsystems which are already available there. In case you want to play around there, send me a mail and I try to get some time to commit some fixes. In case you are interested to work on a subsystem which is not represented there, you can email me too (but it should be easy to copymodify an existing file). But again, no guarantees that any changes to the source get's committed. Bye, Alexander. -- Beware of a tall black man with one blond shoe. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
