Re: install-prompt for missing features (Was: Re: Pull in upstream before 9.1 code freeze?)
Doug Barton do...@freebsd.org wrote: ... something like this would be *really* valuable to ease the transition for people coming from a Linux background. I'm sure some folks here would count this as a reason *not* to provide it :- ___ 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: decoding of multi-byte nops in dtrace
Andriy Gapon a...@freebsd.org wrote:
on 10/06/2012 23:40 Ryan Stone said the following:
On Sun, Jun 10, 2012 at 12:38 PM, Andriy Gapon a...@freebsd.org
wrote:
Do you use -O2 or higher optimization for kernel/modules build?
I use only -O1.
Here are some stats from my system:
$ dtrace -ln fbt::: | fgrep -c entry
16876
$ dtrace -ln fbt::: | fgrep -c return
16729
So, 147 functions without return probe.
Try re-compiling with -foptimize-sibling-calls. That enables
the tail call optimization in gcc, and therefore you get many
functions with no ret instruction (and thus no return probe in
DTrace)
Sounds as if DTrace could use an improvement to recognize and handle
the tail call optimization, maybe something along the lines of:
If a function has no otherwise-determined return probe
and it contains a jump to the entry point of another function
then it inherits that other function's return probe.
I'd expect that to handle cases like
int bar(...)
{
...
return baz;
}
int foo(...)
{
...
return bar(...);
}
(although probably not cases where the return in foo calls a
function pointer). And no, I am not volunteering to add it --
ENOTIME :(
___
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: Ways to promote FreeBSD?
Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Fri, Apr 27, 2012 at 8:06 PM, c.hutchins...@yahoo.com wrote: I'm wondering if spinning up a live DVD desktop version, using GENERIC, and/or Gnome/KDE might be a good option to take FreeBSD for a test drive ... There is such a very nice distribution : http://ghostbsd.org/ Also, freesbie.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: Graphical Terminal Environment
Brandon Falk bfalk_...@brandonfa.lk wrote: I havent tried tmux yet, but on my system im only able to get 80x40 with vidcontrol on one monitor. But with xterm in xorg i can get 319x89 per monitor ... To get higher resolution than what vidcontrol provides, you'll most likely need to run the display in graphic mode (which is what X11 does) rather than in text mode. That means that you will need to either use, or reinvent, the lowest levels of X (display driver, window mapping) and at least part of the xterm/rxvt application (terminal emulation, font rasterizing, perhaps scrolling). You could, however, eliminate the X practice of using the network to connect the terminal emulator to the display; this would give you an architecture resembling SunView (and its predecessor, SunTools). I _think_ SunTools/SunView were proprietary, although it's possible that Sun released the source code at some point. You could try doing some research with Google and/or the Internet Archive. ___ 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: OS support for fault tolerance
Dieter BSD dieter...@engineer.com wrote: The problem then is how to feed both machines the same inputs, and compare the outputs. ??Do we need a third machine to supervise? Can we have each machine keep an eye on the other, avoiding the need for a third machine? A pair would work as long as the only failures are obvious (e.g. crashes). If they simply disagree as to the result, how would we determine which one was right? Which then leads to the issue of how to avoid problems when *it* breaks. For some reason, this reminds me of a Dr. Seuss story: http://www.goodreads.com/review/show/49519038 ___ 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?
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 question: is it in fact noticeably slower to load a minimal kernel plus needed modules than to load a kernel that had all those modules built in? Based on the below, I think we agree that the answer is likely to be no, even if all the modules in question were loaded via loader.conf (and the modular version might well load noticeably _faster_ if a sizeable fraction of the modules could be loaded via kld_list instead). If your question is, 6 + 2-in-loader-conf then I imagine that it would be about the same speed, maybe a little slower due to extra file open-read-close cycles. If it's 6 + 2-in-kld_list then I imagine it would be quite a bit faster than an 8 M kernel ... That is what I would expect, also. but I look forward to the results of your testing. :) You're asking me to test _your_ assertion? I had expected that you would already have the data to back it up. ___ 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?
Doug Barton do...@freebsd.org wrote: loading modules through loader.conf is veeryy slooww ... Is it noticeably slower to load (say) a 6MB kernel + 2MB of modules than to load an 8MB kernel? If so, any idea why? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: easy way to determine if a stream or fd is seekable
Alexander Best arun...@freebsd.org wrote: here's a revised patch. ... +.Sh CAVEATS +If the +.Fn lseek +system call is operating on a device, which is incapable of seeking, +it will request the seek operation and complete successfully. I think it would be better without the first comma (after device). IMO the whole section should be added to BUGS rather than creating a new CAVEATS section. Returning success when the requested operation actually _failed_ is a serious POLA violation. ___ 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: easy way to determine if a stream or fd is seekable
Alexander Best arun...@freebsd.org wrote: since i've never worked with tape: what file type does it identify as? character special file, or block special file, or ...? IIUC all devices are now character, block devices having been dropped from FreeBSD some time ago. Come to think of it, it would not be altogether surprising if that turned out to be the point at which the ability to seek a device went away. ___ 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: easy way to determine if a stream or fd is seekable
Dieter BSD dieter...@engineer.com wrote: IIRC some tape drives can seek, while others cannot. Vague memories that it is supposed to be possible to put a filesystem on a DECtape and mount the filesystem. Back in the Bell Labs 6th Edition days, it was possible to put a filesystem on a _9-track magtape_ and mount it, although such a mount had to be read-only since writing to a 9-track would effectively delete any blocks following the one written. I've done it. Access was painfully slow (no surprise), but it did work. DECtape _could_ be updated in place. It was effectively the linear equivalent of a floppy disk (before floppy disks existed). Sequential access was slow. Random access was very slow. ___ 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: Does anyone use nscd?
Doug Barton do...@freebsd.org wrote: On 10/10/2011 11:55, David Brodbeck wrote: Is there any reason to cache negative hits? It's very important for DNS since there are a fairly large number of misbehaving applications that don't stop querying until they get some kind of answer. Would this need be sufficiently covered if negative cache timeout were set to, say, 1/4 of a second? That should be short enough to cover virtually any instance in which a missing entry is added manually and the new entry then needs to be found. And speaking of DNS, while I think that improving nscd is a good goal I wonder how much use it will be in the world to come when DNSSEC becomes more important ... Is there something about DNSSEC that makes it fundamentally incompatible with a local cache such as nscd, or is it simply a matter of nscd needing a bit of work to support DNSSEC? ___ 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: Does anyone use nscd?
Ivan Voras ivo...@freebsd.org wrote: On 05/10/2011 09:38, Trond Endrest??l wrote: On Wed, 5 Oct 2011 12:54+1030, Daniel O'Connor wrote: In my experience ncsd seems to cache negative hits forever, regardless of the setting for negative-time-to-live. I'm glad to see I'm not the only one who has noticed this odd behaviour of nscd. Shame on me for not speaking up sooner, but I feared I might be proved wrong (again), and yes, that's a lame excuse. :-/ +1. It's very annoying when installing ports which add users - the port adds it then in some future code checks it and it fails. I've noticed it with at least CUPS. Sounds as if there ought to be a unified mechanism for ports to use when adding users, so that necessary notifications -- e.g. restarting nscd if it is running -- can be done in a standardized way and any necessary customizations can be done in a single place. ___ 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: sizeof(size_t) and other semantic types on 32 bit systems?
Lev Serebryakov l...@freebsd.org wrote: GEOM uses 64bit off_t for media size and many other things. off_t is signed! It is ``not accurate enough'' (if you know this Russian joke) :))) g_cache and g_nop use uintmax_t (and no, I don't know the joke). ___ 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: 9-beta1 installer - partition editor
Freddie Cash fjwc...@gmail.com wrote: Unix partitioning has always been this way: - create partition on disk for OS - create sub-partitions for filesystems No, not always. The very first Unix I ever encountered, ATT 6th Edition on a PDP-11/34 with RK05 disks, used what FreeBSD has (until recently) called dangerously dedicated disks. Ditto the first BSD- derived Unix I used, SunOS 3.5 on a Sun-3/160 with the Xylogics SMD disk controller. Of course there was nothing dangerous about it then, because no one had ever heard of installing more than one OS on any given disk pack or cartridge. (Even the large multi-platter disk packs were small enough that one ordinarily needed multiple packs per OS; there was no way anyone would have wanted to squeeze multiple OS onto a pack.) Prior to the IBM PC-AT -- the first PC to have a hard drive -- how many systems _did_ support multiple installs? ___ 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: pub/FreeBSD/releases/i386/8.2-RELEASE/floppies/
Julian H. Stacey j...@berklix.com wrote: With no USB boot, No CD (except maybe pcmcia cdrom that too would need a floppy to start it, Even PL-IP would need a floppy to start with. ... Sure I have other better machines, but this spare old laptop makes a nice spare X screen ... Provided the machine has USB, this http://www.plop.at/ will boot the memstick (at least, it works for me with 8.1). ___ 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: Finding symlink information in MAC Framework
jan.gr...@bristol.ac.uk wrote: On Wed, 27 Jul 2011, per...@pluto.rain.com wrote: ... One additional thing that symlinks manage to do is to refer to directories as well as files Yes; I left that aspect out by way of simplification since it did not seem pertinent to the OP's situation. hard links to directories spawn problems such as requiring garbage collection and smarter filesystem descent algorithms, which is another reason they're typically prohibited except in the case where they're created by mkdir. or by mv, when moving a directory within the same physical filesystem. The two biggest problems I'm aware of are: * They create the possibility that the filesystem is no longer a tree but a more general directed graph which may even be cyclic. The possibility of a cyclic graph would indeed require handling in utilities such as find(1) and ls -R, but the only case I've thought of that would need garbage collection -- as opposed to some minor extension of the current reference-counting scheme -- would be detection of cycles that have become disconnected (unreachable from either the root or any currently-open directory). However, I think prohibition of hard-links to directories is not sufficient to prevent the creation of isolated cycles. Consider: $ mkdir -p /tmp/a/b/c/d/e/f/g $ cd /tmp/a/b/c/d/e $ mv /tmp/a/b f/g Unless either mv or the kernel goes to some trouble to detect the subterfuge, this will create an isolated cycle f/g/b/c/d/e/f/... * Where should my .. entry point, if links to me (other than my . entry and my subdirectories' .. entries) appear in more than one directory? FWIW one of the early unix systems I was exposed to permitted the creation of hard links by arbitrary users. Just _one_? I've never heard of any that did _not_ permit that! (AFAIK Posix requires it.) ___ 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: Finding symlink information in MAC Framework
s s...@samu.pl wrote: ... I am trying to compare the owner of the symlink to the owner of what the symlink points to ... At first I was trying to check wheter some user is trying to create such a symlink ... I've always considered the ownership and permissions of a symlink to be an artifact of the implementation, rather than having any real significance. Symlinks did not exist in Bell Labs Unix, at least as of 6th edition. IIUC they were invented at UCB to get around the limitation that a hard link could not cross a physical filesystem boundary (i.e. a mount point); symlinks would not have been needed had the entire logical filesystem been contained on a single, unpartitioned physical device because hard links could have been used instead. A hard link has no ownership or permissions of its own: it is just an additional directory entry pointing to the same inode as the target's original directory entry. (The permissions are stored in the inode, not in the directory entry.) Because the target of a symlink is (in the general case) not in the same physical filesystem as the symlink itself, the symlink has to be stored in its own inode -- and that inode, like any other, has ownership and permission fields which will inevitably contain some pattern of bits -- but it's not clear to me that anything is gained by assigning a meaning to those patterns. Getting back to the original problem, suppose you had no mounted filesystems (other than special cases like devfs or /proc), the entire logical filesystem tree being stored on a single device, so that any file on the system could be hard-linked into any directory on the system. How would you detect that some user had created a _hard_ link to some arbitrary file? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How can process in STOP state consume 200% CPU?
Yuri y...@rawbw.com wrote: kill -9 doesn't kill it. I think I've seen this before; it looks as if, since the process is STOPped, the kill -9 remains pending rather than being acted upon. I _think_ you can make the process go away by doing a kill -CONT after the kill -9. No idea how a STOPped process can continue to consume CPU, unless in an infinite loop at elevated interupt level (and in that case the kill -CONT may not work -- you may need to drop into kdb, try to do some debugging and/or get a dump, and then reboot). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How can process in STOP state consume 200% CPU?
Yuri y...@rawbw.com wrote: On 06/28/2011 17:24, Sergey Babkin wrote: Most probably the process is running in an endless loop in the kernel mode ... While it's in the kernel mode, you can't do anything to it other than use the kernel debugger. How is this normally possible to make program to loop in kernel mode on -STABLE kernel? Doesn't this mean bug in kernel? In kernel code, but not necessarily in the -STABLE kernel itself -- there could be a problem in a kernel module. I haven't checked, but would not be surprised if VirtualBox included one. ___ 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: tr A-Z a-z in locales other than C
Jilles Tjoelker jil...@stack.nl wrote: On Tue, Jun 07, 2011 at 04:24:43AM +0400, Andrey Chernov wrote: ... Back to the ports: it is not hard to run _any_ port's make or configure with LANG=C directly by the ports Mk system to eliminate that problem. True, but some ports install scripts with problematic tr calls. So part of the porting effort may be to provide a patch that prepends something along the lines of env LANG=C to tr calls in those scripts. It would surely not be the only kind of situation in which a port needed to patch the ported code to get it to run correctly on FreeBSD :) ___ 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: Active slice, only for a next boot
Dieter BSD dieter...@engineer.com wrote: If you neglected to specify RS-232 console in the requirements, there is this thing. ??I haven't tried it. http://www.realweasel.com/ Heard of it, aka the PC Weasel. I've never actually seen one. They have been around for a while; the original -- which they apparently still make -- was ISA. Somebody probably sells a KVM-over-IP box. Raritan, at least. Probably others also. Unfortunately it doesn't have a better way to do this as the only input it gets from boot0 or any other MBR boot loader is the BIOS drive number in %dl. I'm not sure how else you would detect that a non-active slice was booted from when that is your only input. The NetBSD boot code manages to do it. Dunno how NetBSD does it, but one approach that comes to mind would be for whatever installs boot1 to set one of its bytes to the slice number in which it is installed. ___ 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: scd and mcd
Warner Losh i...@bsdimp.com wrote: mcd and scd are ISA-only devices ... They were important for the 386 (now not supported) and 486 machines. Since the 486 machines in question maxed out at 32MB, and 8.x has trouble running in 32MB on x86, I'm guessing there aren't too many 486 SX/DX machines running 8.x. 486 were the last for which ISA was the primary bus, but ISA was still present (bridged from PCI) on most Pentium systems and common at least as recently as Pentium-II. (I don't have a disassembled P-III handy to check whether it has an ISA slot.) ___ 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: ifconfig output: ipv4 netmask format
Warner Losh i...@bsdimp.com wrote: Non-contigous netmasks are legal in IPv4 ... They have become illegal in the fullness of time. and/or the fullness of the address space, I suspect :) Even if they were legal, I have a hard time imagining a practical use case. ___ 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: Kernel Tracking Question.. regarding kernel and boot files
Chuck Swiger cswi...@mac.com wrote: ... Is it better to use Combination of Ecllipse/Qemu and FreeBSD Source tree? Eclipse is an editor ... Eclipse is, or at least can be configured to be, much more than an editor. In my experience it is an integrated development environment incorporating various debugging displays and controls. The OP is presumably referring to a plugin that integrates Qemu into the Eclipse environment. ___ 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: looking for error codes
Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: For a long time I am thinking to obtain a physically ( not only software ) based [read-only] FreeBSD edition by re-arranging some parts of it , but I do not know how to do it ... After some years , MFM hard disks abandoned in favor of IDE ( Integrated Drive Electronics ) hard disks by moving controller to hard disk and eliminating use of add-on cards with a very unfortunate design decision as ( a write protect mechanism by a switch on the hard disks are not implemented ) . At least some IDE drives have write-protect jumpers, which could presumably be replaced with connections to switches. With respect to my knowledge , no one of the operating systems has a facility to separate read-only and modifiable parts ... SunOS 4 had a partial solution to this, by rearranging the FS layout so that /usr could be mounted read-only (and often, from a server -- IIRC a single /usr could be shared among multiple diskless clients). They used quite a few symlinks so that things could be found in their accustomed places although actually located elsewhere. The scheme was fairly well described in the SunOS 4 manual set; granted _finding_ a SunOS 4 manual set these days may be a challenge :) ___ 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: Keeping /etc/localtime up-to-date
Matthias Andree matthias.and...@gmx.de wrote: If they're in the same physical FS there's no need for a symlink. You might as well use a hardlink. And then discuss how all the time zone configuration tools deal with /etc/localtime - truncate/overwrite, direct overwrite ... In that case neither a symlink nor a hardlink is safe, regardless of whether /etc and /usr/share/timezone are in the same FS. Either truncate/overwrite or direct overwrite will trash the target of a symlink just as they would the file identified by a hardlink. ___ 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: Keeping /etc/localtime up-to-date
Matthias Andree matthias.and...@gmx.de wrote: Am 28.03.2011 19:57, schrieb dieter...@engineer.com: I have been running FreeBSD and NetBSD with /etc/localtime being a symlink for years and have not seen any problems as a result. In that case, /etc and /usr/share/timezone (or whatever) need to be in the same physical file system ... If they're in the same physical FS there's no need for a symlink. You might as well use a hardlink. ___ 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'11: DWARF2 call frame information
Xingxing Pan mprc.pku.edu.cn wrote: Dose full register tracking means to emit DWARF for all the registers's saving and restoring in the life time of the function? Most assembly functions are leaves, so saving/restoring around calls to lower-level functions will be infrequent. I suspect it would be more useful to emit debug records that show how the registers are being used, so that gdb can display meaningful names along with their values. And yes, this requires reading and understanding the comments if the code is well commented, or analyzing the code if it is not well commented. It can't be automated. ___ 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: buildkernel error
Dimitry Andric d...@freebsd.org wrote: On 2011-02-22 08:30, gnehzuil wrote: I updated my kernel source code and try to make a new kernel using make buildkernel command. But I got an error as follow: ... ld:/usr/src/sys/conf/ldscript.i386:66: syntax error Your /usr/bin/ld is still at version 2.15, which is too old to parse the kernel linker script. In this case, first run make buildworld, or at least make kernel-toolchain before you attempt to build any kernels. Will either make buildworld or make kernel-toolchain accomplish anything if, as the OP said, s/he only updated the _kernel_ sources? ___ 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: memstick.img is bloated with 7% 2K blocks of nulls
Tim Kientzle t...@kientzle.com wrote: The strategy used by libarchive's recent ISO writer is to concatenate the file bodies into a temp file (with minimal padding between entries to meet alignment requirements) while storing directory information in memory. The final output then consists of the directory information followed by the concatenated file bodies. I suspect a similar strategy could be used to lay out and write a read-only optimized UFS image ... I think it's probably feasible but I doubt very much of the existing UFS code can be recycled for such a project. There was at one time a capability in mkfs(8) -- which no longer even exists as a separate entity, having been absorbed into newfs(8) -- to pre-populate the filesystem with specified content. Dunno if it was ever in any BSD release -- it's not mentioned in the 4.2BSD-derived SunOS 4.1.1 manpage -- so I may be remembering it from Bell Labs 6th edition on the PDP-11. The code to collect and write all of an existing filesystem's directories, followed by all of its files, exists in dump(8). ___ 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: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
Diane Bruce d...@db.net wrote: There certainly would not be a chance of putting mercurial or git into base for example. Completely apart from licensing, another strike against mercurial is that it is written in Python, so it couldn't go into base unless Python also went into base. BTW this topic came up on ports@ about 3 months ago: http://lists.freebsd.org/pipermail/freebsd-ports/2010-September/063675.html ___ 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: best way to run -RELEASE and -CURRENT on the same machine
Warner Losh i...@bsdimp.com wrote: I'd be tempted to run a -current jail inside of an 8.x base system. That's not supported, but would likely work. Only if the OP doesn't need a -CURRENT kernel :) ___ 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: Interactive tool for installing packages
Marin Atanasov Nikolov dna...@gmail.com wrote: in order to install the program, you need to: # git clone git://git.unix-heaven.org/public/pkg_add_it ... Surely, there's room for improvement, but that's a start.. :) Dunno about anyone else, but from my standpoint it would be a _big_ improvement to provide a more recent snapshot than the 6-month-old pkg_add_it-1.2.tar.gz on ftp.freebsd.org so one doesn't have to install git, with its boatload of dependencies*, to see the recent improvements. * The amount of stuff downloaded by cd /usr/ports/devel/git ; make fetch-recursive is, shall we say, impressive. ___ 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: Interactive tool for installing packages
Marin Atanasov Nikolov dna...@gmail.com wrote: If you do not have git installed, you could still get the latest snapshot of pkg_add_it via the Cgit repo. [1] [1] http://git.unix-heaven.org/cgit.cgi/pkg_add_it/ Aha! I'm sure I looked at that page before posting, but did not see how to pull down a snapshot (vs browsing individual files) the first time. It seems to have been reorganized since 1.2, as well as having grown quite a bit :) ___ 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: Slow disk access while rsync - what should I tune?
[missing attribution restored] Matthew Dillon dil...@apollo.backplane.com wrote: per...@pluto.rain.com wrote: :cronfy cro...@gmail.com wrote: : : And also, maybe there are other ways to create incremental backups : instead of using rsync/hardlinks? : :Yes. Use dump(8) -- that's what it's for. It reads the inodes, :directories, and files directly from the disk device, thereby :eliminating stat() overhead entirely. : :Any replication mechanism -- rsync, tar, even dd -- can be used :as a backup mechanism, but dump was specifically designed for the :purpose. Well, dump is 25+ years old ... Why are you running BSD if you prefer newer (= less mature) stuff? Switch to Linux! ... On a modern (large) filesystem you are virtually guaranteed to get corruption due to the asynchronous nature of the dump. This can be partially mitigated by using a block level snapshot on the UFS source filesystem and then dumping the snapshot instead of the live filesystem ... IOW by using dump -L Plus dump uses mtime to detect changes, which is unreliable, ... Are you sure about that? Last I knew it used ctime. and the output produced by dump is not live-accessible whereas a snapshot / live filesystem copy is. That makes the dump fairly worthless for anything other than catastrophic recovery. Ever heard of restore -i? ___ 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: Slow disk access while rsync - what should I tune?
cronfy cro...@gmail.com wrote: And also, maybe there are other ways to create incremental backups instead of using rsync/hardlinks? Yes. Use dump(8) -- that's what it's for. It reads the inodes, directories, and files directly from the disk device, thereby eliminating stat() overhead entirely. Any replication mechanism -- rsync, tar, even dd -- can be used as a backup mechanism, but dump was specifically designed for the purpose. ___ 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: fsync(2) manual and hdd write caching
Ivan Voras ivo...@freebsd.org wrote: ... The problem is actually pretty hard - since AFAIK SoftUpdates doesn't have checkpoints in the sense that it groups writes and all data before can guaranteed to be on-disk, the problem is *when* to issue BIO_FLUSH requests. Seems to me the originally-stated problem -- making fsync(2) do what it claims to do -- is not hard at all. Just issue a BIO_FLUSH request as the final step in handling fsync(2). While we're at it, perhaps do the same in close(2). I _hope_ we are already doing it in unmount(2). ___ 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: fsync(2) manual and hdd write caching
Ivan Voras ivo...@freebsd.org wrote: fsync(2) actually does behave as advertised, auses all modified data and attributes of fd to be moved to a permanent storage device. It is the problem of the permanent storage device if it caches this data further. IMO, volatile RAM without battery backup cannot reasonably be considered a permanent storage device, regardless of where it is physically located. Short of mounting synchronously, with the attendant performance hit, would it not make sense for fsync(2) to issue ATA_FLUSHCACHE or SCSI SYNCHRONIZE CACHE after it has finished writing data to the drive? Surely the low-level capability to issue those commands must already exist, else we would have no way to safely prepare for power off. ___ 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: Timestamps in static libraries
Erik Cederstrand e...@cederstrand.dk wrote: It seems I can at least normalize the .a files using something like the following to weed out timestamps and uid/gid: % ar -x /usr/lib/libfetch.a % chown 0:0 * % touch -t 19700101 * % ar -r libfetch.a `ar -t /usr/lib/libfetch.a` ... Unfortunately it seems there's still a creation time of the archive itself that I cant alter using the above, so the md5 sums still don't match: % diff mod.strings orig.strings 2c2 / 1286312209 0 0 0 958 ` --- / 1269146263 0 0 0 958 ` Any particular reason to recollect them into an archive, if the point is just to check md5 signatures? I'm pretty sure collecting them with tar instead will avoid this problem. ___ 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: adding a new lib for more advanced argument parsing
Alexander Best arun...@freebsd.org wrote: ... getopt(3) is clearly not suitable for handling such complex options. camcontrol.c even contains a whole paragraph about why getopt(3) is considered not appropriate to handle camcontrol's argument parsing requirements ... why not do a vendor import of popt 1.16 e.g.? are there license restrictions? AFAIK it is GPL; it was used in Red Hat Linux prior to the split into Fedora and RHEL (and may still be, for all I know). or maybe some other lib... Dunno what-all may be available. popt has its own set of limitations. Check the archives from the RPM mailing list from around the time when RPM switched to popt, or perhaps it was when rpmbuild was split out into a separate executable, for the laundry list of issues they encountered in attempting to maintain compatibility at the command line level between what they had before and after. ___ 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: ar(1) format_decimal failure is fatal?
Tim Kientzle kient...@freebsd.org wrote: Personally, I wonder if it wouldn't make sense to just always force the timestamp, uid, and gid to zero .. uid and gid, OK. Timestamp, no. It is not that rare to need to find out which version of some .o is in a particular .a file, usually in connection with debugging some obscure failure. For that matter, aren't there some versions of make(1) that can check whether an archive member is up to date by examining the timestamp in the archive? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to disallow logout
Aryeh Friedman aryeh.fried...@gmail.com wrote: I would prefer to have the plain text around after a power failure because it could be several days of work ... Ideally there should be _some_ mechanism for committing unfinished work to a (probably encrypted) repository on, at least, a daily basis. The more I see of this thread, the more it seems that the problem is largely the fault of the particular VCS being used. A VCS that demands a review step before anything can be checked in, even on a work in progress branch as opposed to the mainline, seems a poor fit for a project in which developers are not permitted to see one anothers code. ___ 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: minidump: a hack to prevent vm_page_dump bitmap change during dumping
Matthew Jacob m...@feral.com wrote: ... IMO, the best thing to do is to when you're panicing stop all other CPUs. which is fine _if_ the system is healthy enough to do it. If it's unhealthy enough to be panicing, it may not be healthy enough to be doing IPC operations. ___ 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: Winbond Watchdog
Daniel O'Connor docon...@gsoft.com.au wrote: On 23/08/2010, at 1:24, Xin LI wrote: 2010/8/7 Dag-Erling Sm?rgrav d...@des.no: Xin LI delp...@delphij.net writes: I'm still polishing up the driver, there seems to be no way to figure out the base port address directly (datasheet said it's either 0x2e and 0x4e) so for now I have its device identify method to do some dirty hacks (outb/inb directly) and only check if with appropriate key entered to the port we will get non-0xff value. Sounds gross, but if there's no other way, I guess it'll have to do. I imagine you check the PCI id etc. first? It's not a PCI device unfortunately (at least, not the one I have encountered on my Supermicro board). They're LPC ISA devices, I don't know if they appear in any PNP or ACPI tables though. Any mainboard device on a non-enumerable bus, including LPC, is _supposed_ to be reported in the ACPI tables -- precisely to avoid the need for drivers to engage in risky probing to find their hardware. That's no guarantee of course -- there are plenty of buggy BIOS around -- but it might be worth looking to see if this one got it right. ___ 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] Fix typos in bsd.port.mk and minor logic improvements
Doug Barton do...@freebsd.org wrote: -# UNAUTHORISED CHANGES WILL BE UNCONDITIONALLY REVERTED! +# UNAUTHORIZED CHANGES WILL BE UNCONDITIONALLY REVERTED! ... The above is not a typo, that's the British spelling. ... (Arguably it adds character to the project.) :) Er, this example just changes one character without adding any :) [ducks] ___ 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: Help with some makefile hackery
Patrick Mahan ma...@mahan.org wrote: Maybe I should do this instead? src-kernel: src-kernel-tools cd src; ./amd64-kernel.sh 21 build_amd64_kernel.log; \ tail -f build_amd64_kernel.log It is not too clear if the status is the last one in a compound command. Someone already noted that this will not run tail until after the build finishes; then you'll see the last 10 lines of the log and make will stop until something (like kill) causes tail to exit. Another problem arises from the order of the redirections: only the script's normal output will go to the logfile; errors will go to make's standard output. This should do more or less what I think you're trying for: src-kernel: src-kernel-tools touch src/build_amd64_kernel.log tail -f src/build_amd64_kernel.log cd src; ./amd64-kernel.sh build_amd64_kernel.log 21 IOW start tail in the background, after ensuring that the logfile exists so tail doesn't immediately exit with an error. Note that this does not solve the problem of somehow getting rid of the tail process after the build finishes. ___ 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: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
Gary Jennejohn gljennj...@googlemail.com wrote: IMO if you're going to make the binaries in base non-executable you might just as well delete them. The chmod is reversible without having to recover the base binaries from somewhere. ___ 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: close() failing with ECONNRESET
Timo Sirainen t...@iki.fi wrote: I see that since FreeBSD 6.3 close() can fail with: [ECONNRESET]The underlying object was a stream socket that was shut down by the peer before all pending data was delivered. Could someone explain what this is useful for? Consistency with SIGPIPE, perhaps? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to get stack bounds of current process?
Lev Serebryakov l...@freebsd.org!lev@agora.rdrop.com wrote: I'm not sure, should BSD port behaves as Linux or as Solaris one. Based solely on heritage, I suspect the Solaris approach might fit more comfortably. Solaris comes from SVR4, which was supposed to be the great reunification of SysV and BSD, and so has 4.3 BSD in its ancestry -- as does FreeBSD. Linux is a from scratch reimplementation of the SVID which deliberately included no SysV or BSD code. ___ 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: disabling all serial input / output at boot time
Mike Tancsa m...@sentex.net wrote: I have an embedded device (Alix box) that is running RELENG_8 off a CF that is designed to monitor / control a serial sensor device. The sensor is quite chatty and is always outputing data at 115200. The problem is that this will interrupt the boot process. I even tried to fake it out, but trying to make com2, the console in /boot/device.hints ... Is there any way to completely disable serial interaction and to truly make the bootup process quiet and non interactive ? More of a workaround than a fix, but does it work any better if you connect the device to com2 instead of com1? ___ 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: Another tool for updating /etc -- lua||other script language bikeshed
Robert Watson rwat...@freebsd.org wrote: ... web browsers [are] basically operating systems at this point ... Isn't this a bit of an exaggeration? Not too many browsers have to deal with process/thread scheduling, or device drivers, or booting, or file system issues -- they rely on the OS for that (as does any other application). ___ 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: Does FreeBSD issue messages about MAC/IP conflicts?
Glen Barber glen.j.bar...@gmail.com wrote: On Sun, Jan 3, 2010 at 6:40 PM, Yuri y...@rawbw.com wrote: I accidentally had two machines having the same wifi MAC address. Wifi router gave them both the same local IP address and they both could somewhat connect to the outside world, but connections were flaky. No messages about IP/MAC conflicts appeared in dmesg log. Vague memories from the long ago past remind me that Windows was issuing IP conflict messages in the local wired network. Why doesn't FreeBSD complain at leat about the IP conflict? The last time I made the mistake of having two devices with the same IP, I saw ARP messages in /var/log/messages as well as the system console. This was around 8.0-RC1, for what it's worth. ARP will notice when two different MAC addresses both claim the same IP address, but to detect two different boxes both claiming the same MAC/IP address pair would require some other way of identifying the two boxes as different. ___ 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: Wine on amd64 in 32 bit jail
KAYVEN RIESE ska...@fsu.edu wrote: Is there any reason to fear Microsoft viruses infecting Wine programs? In principle, yes, because Wine is supposed to be a complete reimplementation of the win32 API, thus any program that runs differently on Wine than on Windows demonstrates a bug in Wine. (IIRC there are a few Windows viruses that do run on wine.) In practice, any Wine bug that impairs only viruses will probably not be a high priority to get fixed :) ___ 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: SGID/SUID on scripts
Ivan Voras ivo...@freebsd.org wrote: 2009/7/23 per...@pluto.rain.com: Ivan Voras ivo...@freebsd.org wrote: Presumingly, the biggest concern is with scripts owned by root. Who can unlink, move or change the script? The owner and his group can change it; the directory owner can unlink it ... Anyone can make a link to such a script in, say, /tmp and then mess with the link :( You mean setuid a soft link? That's allowed? One can certainly make a symlink that points to a setuid file. The permissions of the symlink itself don't matter. IIRC the original demonstration that this exposure was real and not just theoretical involved making -- and subsequently messing with -- a hard link in /tmp to a setuid script in /bin, /tmp and /bin both being on the root FS. (This was before machines commonly had enough RAM for tmpfs to be practical, and may have been before symlinks even existed.) Granted a case can be made for making /tmp a separate FS in any event, but of course it would have worked just as well to make a link in /usr/tmp to a setuid script in /usr/bin, etc. The only way to avoid the exposure would have been to ensure that no possible attacker would have write permission to any directory on the same FS as a setuid script to which the attacker had execute permission -- not the easiest thing to keep track of on an ongoing basis. With the existence of symlinks I suspect even that would no longer help. ___ 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: SGID/SUID on scripts
Ivan Voras ivo...@freebsd.org wrote: Presumingly, the biggest concern is with scripts owned by root. Who can unlink, move or change the script? The owner and his group can change it; the directory owner can unlink it ... Anyone can make a link to such a script in, say, /tmp and then mess with the link :( ___ 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: SGID/SUID on scripts
DarkSoul darks...@darkbsd.org wrote: Anthony Pankov wrote: SGID/SUID bits don't work with shell scripts, do they? They don't. ... if they were applied, the following would occur : - execve() syscall reads your script's shebang line, and the script interpreter is executed, receiving the specified arguments along with the script name. - The interpreter then open()s the script file to read it, and run the code. The problem you then are faced with, is that you have a time frame defined by the moment between the aforementioned execve() and open(), during which it could be possible to unlink/move/ whatever the shell script the interpreter is going to open. You guess where this is going, you have no absolute way of guaranteeing you are executing the file you initially planned on opening because execution/opening/reading is not, and can't be done atomically for shell scripts. In principle, it should be possible to fix this exposure by improving the interface between execve() and the interpreter: The execve() syscall already has the script file open to read the shebang line. Leave it open, and ensure that the interpreter receives the open descriptor as fd#3 just as 0, 1, and 2 are already used for stdin, stdout, and stderr. An interpreter supporting this approach would check whether stdscr (fd#3) is already open, and if so read from it instead of open()ing the script file. This should ensure that the script which gets executed is the same inode on which execve() saw the SGID/SUID bits set, even if the filesystem has been changed by the time the interpreter has gotten started. It would be the responsibility of whomever decided to set the SGID/SUID bits on a particular script to ensure that the interpreter involved supports the mechanism. I vaguely recall having seen a similar (or even identical) approach suggested some years ago. It may even have been implemented in some variant of Un*x. ___ 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: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls?
Nate Eldredge neldre...@math.ucsd.edu wrote: For instance, consider the following program. snip this happens most of the time with fork() ... It may be worthwhile to point out that one extremely common case is the shell itself. Even /bin/sh is large; csh (the default FreeBSD shell) is quite a bit larger and bash larger yet. The case of big program forks, and the child process execs a small program arises almost every time a shell command (other than a built-in) is executed. With overcommit, we pretend to give the child a writable private copy of the buffer, in hopes that it won't actually use more of it than we can fulfill with physical memory. I am about 99% sure that the issue involves virtual memory, not physical, at least in the fork/exec case. The incidence of such events under any particular system load scenario can be reduced or eliminated simply by adding swap space. ___ 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: SoC2009: libpkg, pkg tools rewrite
David Forsythe freebsd.org!dfors...@agora.rdrop.com wrote: This summer I'll be working on creating a package library and using that library to rewrite the pkg tools ... As of last July there seemed to be no way to specify a mixture of local and remote repositories for pkg_add (discussion here): http://lists.freebsd.org/pipermail/freebsd-questions/2008-July/178710.html It would be good to get that capability added if it has not already been done. ___ 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: compiling root filesystem into kernel (preferably tmpfs root filesystem)
Travis Daygale anti_spam...@yahoo.com wrote: I have built a root image that I put in the kernel as described in the Nov 2006 post. ?My UFS root image consists of /sbin/init, where init is a statically compiled C program that just spits out Hello world and sleeps, this binary runs fine under FBSD. ?At this point, I have the kernel booting but it panics because it says it can't find init ?Hmmm... ?I believe (haven't had time to test) that it is finding root? Yes, if it gets to the point of can't find init it has already successfully mounted the root filesystem (although, perhaps, not the *intended* root filesystem). ___ 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 the mss for socket
Luiz Otavio O Souza lists...@gmail.com wrote: Is there a way to set the mss for a socket ? Like you can do in linux with setsockopt(TCP_MAXSEG) ? So i can set the maximum size of packets (or sort of) from a simple userland program. Depending on exactly what you need to accomplish, you may find something useful in this thread from last August in freebsd-questions@ setting the other end's TCP segment size ___ 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: 2 uni-directional TCP connection good?
What I meant was that there were cases when a receiver could not tell weather no data was coming or communication was interrupted. Once connection is established, a route is available between a server and a client. Let's say this route is broken for some reasons, i.e. someone unplugged a cable or a firewall started dropping or rejecting between these server and client, a sender may not notice as soon as it happens but at least, a sender knows a massages was not delivered right. On the other hand, receiver side does not have any idea that a message delivery failure has happened at all or for a while unless using heartbeat messages in upper layer. KEEP_ALIVE option seems to be implementation dependent such that you cannot assure TCP connection availability for every minute. The whole point of TCP (vs IP alone, or UDP) is to establish reliable end-to-end communication over unreliable underlying links. If a packet is corrupted or lost, it gets resent. If a route goes down, and an alternate is available, TCP will -- eventually -- find it and recover. If the last (or only) route goes down, TCP will in principle wait indefinitely for a route to become available, whether by reestablishment of the original or provision of an alternative. So you are correct that a receiver can't tell the difference between a loss of connectivity and the sender having crashed, however the situation is entirely symmetric: the sender can't tell the difference either. It all gets sorted out when communication is reestablished; at that point traffic will resume (if the link had been down) or the uncrashed end will get a connection reset (if its peer had crashed). The practice of sending keep-alive packets simply converts a temporary (thus potentially recoverable) communication loss into what amounts to an unrecoverable crash of whichever end gets impatient first. ___ 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: hosted, or not (Re: Renaming all symbols in libmp(3))
Roman Divacky freebsd.org!rdiva...@agora.rdrop.com wrote: On Thu, Feb 26, 2009 at 11:46:22PM -0800, per...@pluto.rain.com wrote: By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default ... ... it's invalid code to have a function named pow() in a hosted environment which is not /The/ pow(). ^^^ I don't suppose LLVM supports a commmand-line switch to use embedded mode instead of hosted? of course it does -ffreestanding So perhaps one solution would be to compile libmp with -ffreestanding? ___ 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
hosted, or not (Re: Renaming all symbols in libmp(3))
By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default ... ... it's invalid code to have a function named pow() in a hosted environment which is not /The/ pow(). ^^^ I don't suppose LLVM supports a commmand-line switch to use embedded mode instead of hosted? ___ 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: /dev/dsp* /dev/audio* devices not present
Rick C. Petty rick-freebsd2...@kiwi-computer.com wrote: On Sat, Jan 10, 2009 at 04:20:58AM -0800, per...@pluto.rain.com wrote: Rick C. Petty rick-freebsd2...@kiwi-computer.com wrote: That's not how devfs works. It's actually a feature that devfs doesn't list everything ever possible http://storage9.myopera.com/freejerk/files/bug-feature.jpg Funny. But this isn't a bug disguised as a feature. It's a feature that you believe is a bug. I would call it a bug that you believe is a feature. I'd rather be able to list to see things that are in use, although at first glance I didn't like devfs hidden nodes. Otherwise you'd be stuck printing tunXXX through infinity instead of this: % ls /dev/tun* /dev/tun0 /dev/tun115 /dev/tun194 In any other part of the directory tree we expect ls to provide a list of names that are available to be opened (subject to permissions). Why should /dev be any different? Because it's a special filesystem. I think that constitutes an admission that it violates POLA, and it's not much of a justification IMO. Since you aren't supposed to open (say) /dev/tun85, but only /dev/tun0, correspondence between readdir and open would not demand What? Why aren't you supposed to open tun85? I use this behavior all the time and have for years. It helps keep track of things. Otherwise I would have to keep my natd configuration, firewall rules, and openvpn configuration all in sync. Please provide a reference describing you're not supposed to open any arbitrary tunnelling device. The manpage for tun(4) says: tun does for network interfaces what the pty(4) driver does for terminals ... The network interfaces are named ``tun0'', ``tun1'', etc., one for each control device that has been opened ... The tun interface permits opens on the special control device /dev/tun. When this device is opened, tun will return a handle for the **lowest** unused tun device ... (emphasis added). The whole point of cloning devices is to avoid the need for the application to loop through a sequence of possible names to find one that is not in use; it simply opens the generic name and gets a (pseudo) device. BTW I was slightly off -- it is /dev/tun rather than /dev/tun0 that's supposed to be opened -- but if anything this strengthens my point (see below). that readdir return the (large, if not infinite) list of potential instances. It would however seem reasonable for that ls command to show /dev/tun0 if its driver is loaded, even if the device has not been instantiated because the node has never been opened. I don't buy that argument at all. If anything it should show /dev/tun, Agreed it should be /dev/tun -- see above. but why create device nodes when they aren't necessary, as you have to clone the nodes (or create new ones) when an actual open(2) occurs? As I stated earlier in this thread: * It doesn't necessarily need to actually create them, but the * results from readdir(2) should be as if they had been created. This is not a bug, it is designed behavior. It was intentionally written to dynamically create device nodes when needed. That the code faithfully adheres to the design does not guarantee that the design is flawless. IMO it violates POLA, if not POSIX, Please provide the reference where it violates POSIX. I am not familiar with POSIX in detail, which is why I only suggest that it *may* violate POSIX. You're welcome to research the matter. I would *expect* that research to find that there is supposed to be a correspondence between what readdir reports as the contents of a directory, and the results of attempting to open a filename in the directory whose contents were read; if not, what would be the point of having readdir in the first place? for open(2) to succeed when applied to a name which, according to readdir(2), does not exist; What? This can happen already-- there is no atomicity between a readdir and an open. Of course not, but we are not dealing here with a case in which process A reads the directory, then process B creates a file in it, and thus that file becomes visible to process A. Instead we have a magical side-effect, wherein process A opens a file which (per readdir) does not exist, and thereby calls into existence a new file, while the name that process A opened *still* does not exist. And what about msdosfs and case-insensitivity? You can certainly open files that weren't a part of your readdir. The semantics of msdosfs are driven by the need to maintain compatibility with a certain other operating system -- the one which defined that filesystem representation in the first place. I hardly think it should be considered a good precedent. Also no one in their right mind would be coding a readdir/open solution against a filesystem known to be completely dynamic and especially against devfs. You would want to tie in directly to devctl,
Re: /dev/dsp* /dev/audio* devices not present
Ulrich Spoerlein gmail.com!uspoerl...@agora.rdrop.com wrote: On Thu, 08.01.2009 at 21:50:47 -0800, per...@pluto.rain.com wrote: Ulrich Spoerlein gmail.com!uspoerl...@agora.rdrop.com wrote: Ummm, out of curiosity, are your receiving your mail via UUCP? :) http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020645.html ___ 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: /dev/dsp* /dev/audio* devices not present
Rick C. Petty rick-freebsd2...@kiwi-computer.com wrote: On Thu, Jan 08, 2009 at 09:50:47PM -0800, per...@pluto.rain.com wrote: In principle, everything that would be successfully created if open(2)'ed. It doesn't necessarily need to actually create them, but the results from readdir(2) should be as if they had been created. The whole point of things like ls(1) and readdir(2) is to find out what-all is available to be opened, without having to already know the answer. That's not how devfs works. It's actually a feature that devfs doesn't list everything ever possible http://storage9.myopera.com/freejerk/files/bug-feature.jpg (things looked terrible back in the old MAKEDEV days with all those polluted names). Yes, MAKEDEV can create the opposite problem, wherein /dev contains nodes for devices whose drivers and/or hardware aren't present. Such orphan nodes aren't a whole lot better than missing nodes. I'd rather be able to list to see things that are in use, although at first glance I didn't like devfs hidden nodes. Otherwise you'd be stuck printing tunXXX through infinity instead of this: % ls /dev/tun* /dev/tun0 /dev/tun115 /dev/tun194 In any other part of the directory tree we expect ls to provide a list of names that are available to be opened (subject to permissions). Why should /dev be any different? Since you aren't supposed to open (say) /dev/tun85, but only /dev/tun0, correspondence between readdir and open would not demand that readdir return the (large, if not infinite) list of potential instances. It would however seem reasonable for that ls command to show /dev/tun0 if its driver is loaded, even if the device has not been instantiated because the node has never been opened. This is not a bug, it is designed behavior. It was intentionally written to dynamically create device nodes when needed. That the code faithfully adheres to the design does not guarantee that the design is flawless. IMO it violates POLA, if not POSIX, for open(2) to succeed when applied to a name which, according to readdir(2), does not exist; and it is suboptimal to have stealth drivers whose availability for use cannot be discovered by examining /dev. ___ 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: /dev/dsp* /dev/audio* devices not present
Ulrich Spoerlein gmail.com!uspoerl...@agora.rdrop.com wrote: I cannot really comment on the devfs(4) design issues, and quite frankly it hasn't bothered my thus far. It evidently inconvenienced the OP. Just another little quirk you get to remember. If we followed that line of reasoning to its logical conclusion we would eliminate POLA entirely. IMO it violates POLA, if not POSIX, for open(2) to succeed when applied to a name which, according to readdir(2), does not exist; and it is suboptimal to have stealth drivers whose availability for use cannot be discovered by examining /dev. You forgot directories with --x permissions. You can open many files inside them, but readdir(2) will get you nowhere. So this is a poor standard by which to judge devfs(4) device cloning. There are at least two problems with that analysis: * /dev does not ordinarily have --x permissions. Even if I amended the principle to allow for that case, it would not affect its application to this case. * readdir works for root, even in directories with --x permissions. For example: $ mkdir test $ touch test/file $ ls -la test total 4 drwxr-xr-x 2 perryh perryh 512 Jan 10 15:39 . drwxr-xr-x 3 perryh perryh 512 Jan 10 15:39 .. -rw-r--r-- 1 perryh perryh0 Jan 10 15:39 file $ chmod 111 test $ ls -ld test d--x--x--x 2 perryh perryh 512 Jan 10 15:39 test $ ls -la test total 0 ls: test: Permission denied # ls -la test total 4 d--x--x--x 2 perryh perryh 512 Jan 10 15:39 . drwxr-xr-x 3 perryh perryh 512 Jan 10 15:39 .. -rw-r--r-- 1 perryh perryh0 Jan 10 15:39 file ___ 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: /dev/dsp* /dev/audio* devices not present
Ulrich Spoerlein gmail.com!uspoerl...@agora.rdrop.com wrote: Please run % cat /dev/sndstat % ls -l /dev/dsp0 /dev/dsp0.0 The reason you are not seeing them with 'ls /dev/dsp*' is because devfs is creating the nodes when they are open(2)'ed. Using shell globbing will search the output of readdir(2) for matches to dsp* where devfs has no way of dynamically creating nodes (which ones should it create anyway?) In principle, everything that would be successfully created if open(2)'ed. It doesn't necessarily need to actually create them, but the results from readdir(2) should be as if they had been created. The whole point of things like ls(1) and readdir(2) is to find out what-all is available to be opened, without having to already know the answer. This is a FAQ really. It may be an FAQ, but it is also a bug, granted one that may not be easy to fix. ___ 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: ichwd problem: watchdog doesn't bark
[dropped stable@ since I'm not on it and I suspect it may not accept non-member posts] BTW, can someone knowledgeable tell me if watchdog better be firing SMI or NMI when it runs down? My bet is on NMI, but who knows. It may depend on whether you want the BIOS, or FreeBSD, handling the interrupt. Unless you are running *very* old h/w, there's a good chance the BIOS intercepts SMI, even with a protected-mode OS running, and I wouldn't be surprised if the BIOS' response to a watchdog timeout were an immediate reboot. It might be good to check the motherboard and/or BIOS manuals. Or maybe I am trying to ask a different question. I see that NMI2SMI_EN bit of TCO1_CNT is set 1 on my machine and our watchdog driver is careful to preserve this bit unmodified. This means that watchdog would try to cause SMI instead of NMI. On the other hand I see that bit GBL_SMI_EN of SMI_EN is set to zero, which means that chipset would never generate an SMI. So I think this is why I don't see anything happening. Now, would should try first - reset NMI2SMI_EN to zero or set GBL_SMI_EN to 1? If you want to handle the interrupt in FreeBSD, I'd try resetting NMI2SMI_EN to zero. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to build kernel module spread on subdirectories?
As you discovered, includes are done before targets. You would need seperate invocations of make, to generate the file and get it included. heresy Provided the module in question is contemplated for delivery as a port, rather than as part of the base -- so that having a build dependency on a port is tolerable -- perhaps it would be more easily built using devel/gmake? /heresy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help in this case. Not sure I understand what is meant by unexpanded here, since it looks as if this sed example would convert an expanded form -- containing the version info -- to an unexpanded one that merely shows where that info should go. Perhaps it's my ClearCase background showing through, but I'd think it highly desirable for a patch to include what I think of as the expanded tag line -- including the version info, as it appears in the distributed files under /usr/src -- thereby explicitly showing the version on which the patch is based (the base contributor in ClearCase-speak). This should greatly simplify merging in the (likely) event that other development has occurred on the same file in the meantime -- provided one is using a 3-way merge tool that understands such things. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
Tim Kientzle [EMAIL PROTECTED] wrote: ... most of us are volunteers who enjoy using and working on FreeBSD in our (often quite limited) spare time ... If I only have a couple of hours a week, I'd usually rather spend it coding ... Sounds familiar :) Getting back to the OP's original question, and in light of the limited time that many of us have available, I was wondering which of the readily-available VCS would impose the least overhead on someone who has very little experience with any open source VCS (and thus is going to have to learn *something* new). After looking at the pages recommended by others in this thread, I wonder if there are other possibilities which one should consider. * http://wiki.freebsd.org/SubversionPrimer I got the impression that SVN is quite resource-hungry, both in disk space and in bandwidth, and has an extremely steep learning curve. While a committer clearly has to deal with SVN, I was left wondering if it really had much to offer the more casual hacker, esp. one who is not already familiar with it. In particular, given that one will likely have already installed /usr/src/... from the distribution, I was put off by the apparent need to download another entire instance. * http://wiki.freebsd.org/LocalMercurial This seems less of a resource hog, and (if I am understanding matters correctly) is able to start from the installed /usr/src/... rather than requiring the would-be hacker to download a redundant instance, but I was concerned that the page may not be up to date with current FreeBSD development methodology (e.g. csup vs cvsup). In case it makes any difference, I've used SCCS and RCS a little (but neither all that recently), and have been using ClearCase a great deal for the last several years (but it is not a candidate for this inquiry since I'm not licensed to use it outside the office). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Increasing partition size by removing partitions
I have a disk that is laid out with partion 0 being NTFS and 1 being FreeBSD. I want to remove the NTFS partition and grow the FreeBSD one but all the docs I have seen only talk about how to do this if the new part of the partition is at the end of the partition you wish to grow. How do I go about this? Partition Commander is aware of *BSD partitions and should be able to do this. (Granted it is payware.) Delete the NTFS partition, move the FreeBSD partition (slice in FreeBSD parlance) to the beginning of the drive, boot into FreeBSD to make sure everything is working, then go ahead with the grow operation as usual. As always, it's highly recommended to make a full backup first. Having done that, it may be easier to reslice the disk as FreeBSD only and then restore the backup. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Securelevels
[EMAIL PROTECTED] /usr/home/strato]$ sudo sysctl kern.securelevel kern.securelevel: 2 [EMAIL PROTECTED] /usr/home/strato]$ kgdb kgdb: /dev/mem: Permission denied [EMAIL PROTECTED] /usr/home/strato]$ sudo kgdb [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] I am running in securelevel 2. That means nithing can have direct access to /dev/mem, acording to man security: 1 Secure mode - ... /dev/mem and /dev/kmem may not be opened for writing; ... ^^^ 2Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not ... So is this a bug I don't think so, because kgdb does not ordinarily need to open /dev/kmem for writing. Presumably you'd get an error if you tried to patch the running kernel. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD license compatible hash algorithm?
Aryeh M. Friedman [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dag-Erling Sm??rgrav wrote: Aryeh M. Friedman [EMAIL PROTECTED] writes: All hashs have issues with pooling see http://www.burtleburtle.net/bob/hash/index.html... btw it is a old wives tale that the number of buckets should be prime (mostly based on the very weak implementation Knuth offered) Not an old wives' tale, but rather an easy way to implement a hash algorithm that is good enough for most simple uses: metric modulo table size, where metric is a number derived from the item in such a manner as to give a good spread. ... the above only applies if your using a very primitive hash like Knuth's multiplication one every modern hash I know of should have 2^k buckets actually for some k ... It very much depends on what is used for a rehash (collision step) value. The step value and the table size must have no common factor larger than 1, or there will be edge cases (bugs) in which some combinations of hash and step values will cause the table to appear full when in fact it is not. Making the table size prime is one simple way of preventing such problems, while still allowing the rehash value to depend on the key (thus reducing the liklihood of collision on the second probe). At the other extreme, the table can be any size at all if the step value is 1 (and the modulo table size operation will certainly be more efficient if the table size is 2^k). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Architectures with strict alignment?
M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Ivan Voras [EMAIL PROTECTED] writes: : Which of the architectures FreeBSD supports (if any) have strict : memory alignment requirements? (in the sense that accessing a : 32-bit integer not aligned on a 32-bit address results in a : hardware trap/exception). Sparc64, powerpc, arm, and (thanks to Juniper and others) mips. The degree to which a PowerPC imposes a strict alignment requirement depends on both the particular processor model and the operation being performed. For ordinary integer arithmetic and logical operations, newer PPC processors tend to be more tolerant (although misalignment will typically carry a performance penalty). For the semaphore primitives (lwarx/stwcx.) most PPC will require proper alignment and some will fault if the operand address is cache-inhibited (even though correctly aligned). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Architectures with strict alignment?
Ivan Voras [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: The degree to which a PowerPC imposes a strict alignment requirement depends on both the particular processor model and the operation being performed. For ordinary integer arithmetic and logical operations, newer PPC processors tend to be more tolerant (although misalignment will typically carry a performance penalty) ... How would it behave in operations like x = x + 1 where x is unaligned in memory? A RISC would have to load the value from memory, increment it and store it. It depends on the processor type. IIRC most of the recent ones (7xx, 74xx) will handle it in hardware, taking a few extra cycles to do the extra memory accesses. Some of the older ones (403) will take an alignment exception, which can potentially be fixed up by a handler but at a cost of, at least, hundreds of cycles -- and only if the OS or the application has provided the handler. I recently ran into a case where a PPC970 took an alignment exception on something resembling this, but I think it was because the data cache was disabled (the 970's hardware misalignment handler being part of the cache logic). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: double panic, and whats apic_cmd? (kqemu crash...)
Oh and I left memtest86 running on that box overnight and it found nothing... well, it could be a kqemu bug I guess, but your panics look like seemingly random memory corruptino as you have stack traces where functions are calling other functions that the don't actually call in the source code. Dunno if this is even *possible* on amd64, but if this were a PowerPC (or MIPS) I would be looking for cache-coherency problems. P.S. If responding, pls include -hackers@ or Cc: me, as I am not on [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault degaradation performance
how to reduce the number of page faults to upgrade program or OS performance? Install more memory. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: timezone printing in date messed up?
$ sh 'EOF' for a in 0 1 2 3 4 5 6 7 8 9 10 11 12 do date -j -f %s `expr 1194163200 + 600 \* $a` done EOF snip buggy output OS X Leopard has the same bug ... How did you test it in Leopard? I tried it in Tiger, intending to contribute another data point, and I got: date: illegal option -- j usage: date [-nu] [-r seconds] [+format] date [cc]yy]mm]dd]hh]mm[.ss] The Tiger manpage gives no obvious equivalent to FreeBSD's -j ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: timezone printing in date messed up?
OS X Leopard has the same bug ... How did you test it in Leopard? I tried it in Tiger, intending to contribute another data point, and I got: Leopard's /bin/date accepts -j. You can try compiling FreeBSD date on Tiger. I had decided against that, since it would propagate the bug if it happened to be in the FreeBSD /bin/date. It turns out the output conversion can be tested using -r: for a in 0 1 2 3 4 5 6 7 8 9 10 11 12 do date -r `expr 1194163200 + 600 \* $a` done and this gives correct results in both Tiger and 6.1: Sun Nov 4 01:00:00 PDT 2007 Sun Nov 4 01:10:00 PDT 2007 Sun Nov 4 01:20:00 PDT 2007 Sun Nov 4 01:30:00 PDT 2007 Sun Nov 4 01:40:00 PDT 2007 Sun Nov 4 01:50:00 PDT 2007 Sun Nov 4 01:00:00 PST 2007 Sun Nov 4 01:10:00 PST 2007 Sun Nov 4 01:20:00 PST 2007 Sun Nov 4 01:30:00 PST 2007 Sun Nov 4 01:40:00 PST 2007 Sun Nov 4 01:50:00 PST 2007 Sun Nov 4 02:00:00 PST 2007 but the original command, run in 6.1, exhibits the bug: for a in 0 1 2 3 4 5 6 7 8 9 10 11 12 do date -j -f %s `expr 1194163200 + 600 \* $a` done Sun Nov 4 01:00:00 PDT 2007 Sun Nov 4 01:10:00 PDT 2007 Sun Nov 4 01:20:00 PDT 2007 Sun Nov 4 01:30:00 PST 2007 Sun Nov 4 01:40:00 PST 2007 Sun Nov 4 01:50:00 PST 2007 Sun Nov 4 01:00:00 PDT 2007 Sun Nov 4 01:10:00 PDT 2007 Sun Nov 4 01:20:00 PDT 2007 Sun Nov 4 01:30:00 PST 2007 Sun Nov 4 01:40:00 PST 2007 Sun Nov 4 01:50:00 PST 2007 Sun Nov 4 02:00:00 PST 2007 Maybe this helps someone familiar with the internals of /bin/date fix it in time for next fall :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
improvement to split(1)
In the case where the output files from split(1) are of a specified
size (in bytes) and the size of the input is known, it is possible
to compute the minimum required suffix_length rather than requiring
it to be specified or accepting the default (2). The attached diffs
add a -B switch, which requests that automation and otherwise behaves
the same as -b.
*** split.1.origSun Jan 16 23:44:29 2005
--- split.1 Sat Aug 4 22:46:19 2007
***
*** 30,38
.\ SUCH DAMAGE.
.\
.\ @(#)split.1 8.3 (Berkeley) 4/16/94
! .\ $FreeBSD: src/usr.bin/split/split.1,v 1.15 2005/01/17 07:44:29 ru Exp $
.\
! .Dd July 12, 2004
.Dt SPLIT 1
.Os
.Sh NAME
--- 30,38
.\ SUCH DAMAGE.
.\
.\ @(#)split.1 8.3 (Berkeley) 4/16/94
! .\ $FreeBSD: src/usr.bin/split/split.1,v 1.15+ 2005/01/17 07:44:29 ru Exp $
.\
! .Dd August 4, 2007
.Dt SPLIT 1
.Os
.Sh NAME
***
*** 41,47
.Sh SYNOPSIS
.Nm
.Op Fl a Ar suffix_length
! .Op Fl b Ar byte_count[k|m]
.Op Fl l Ar line_count
.Op Fl p Ar pattern
.Op Ar file Op Ar name
--- 41,47
.Sh SYNOPSIS
.Nm
.Op Fl a Ar suffix_length
! .Op Fl {b|B} Ar byte_count[k|m]
.Op Fl l Ar line_count
.Op Fl p Ar pattern
.Op Ar file Op Ar name
***
*** 79,84
--- 79,92
is appended to the number, the file is split into
.Ar byte_count
megabyte pieces.
+ .It Fl B
+ Like
+ .Fl b,
+ and compute the
+ .Ar suffix_length
+ based on the
+ .Ar byte_count
+ and the file size.
.It Fl l
Create smaller files
.Ar n
*** split.c.origSun Jul 11 07:44:23 2004
--- split.c Sat Aug 4 23:01:08 2007
***
*** 32,38
*/
#include sys/cdefs.h
! __FBSDID($FreeBSD: src/usr.bin/split/split.c,v 1.15 2004/07/11 14:44:23 tjr
Exp $);
#ifndef lint
static const char copyright[] =
--- 32,38
*/
#include sys/cdefs.h
! __FBSDID($FreeBSD: src/usr.bin/split/split.c,v 1.15+ 2004/07/11 14:44:23 tjr
Exp $);
#ifndef lint
static const char copyright[] =
***
*** 61,66
--- 61,69
#include regex.h
#include sysexits.h
+ #include sys/types.h
+ #include sys/stat.h
+
#define DEFLINE 1000/* Default num lines per file.
*/
off_t bytecnt; /* Byte count to split on. */
***
*** 70,77
char bfr[MAXBSIZE]; /* I/O buffer. */
char fname[MAXPATHLEN]; /* File name prefix. */
regex_trgx;
! intpflag;
! long sufflen = 2; /* File name suffix length. */
void newfile(void);
void split1(void);
--- 73,80
char bfr[MAXBSIZE]; /* I/O buffer. */
char fname[MAXPATHLEN]; /* File name prefix. */
regex_trgx;
! intpflag, Bflag;
! long sufflen = -2; /* File name suffix length, -2 = unspecified. */
void newfile(void);
void split1(void);
***
*** 85,94
long scale;
int ch;
char *ep, *p;
setlocale(LC_ALL, );
! while ((ch = getopt(argc, argv, -0123456789a:b:l:p:)) != -1)
switch (ch) {
case '0': case '1': case '2': case '3': case '4':
case '5': case '6': case '7': case '8': case '9':
--- 88,98
long scale;
int ch;
char *ep, *p;
+ struct stat istat;
setlocale(LC_ALL, );
! while ((ch = getopt(argc, argv, -0123456789a:b:l:p:B:)) != -1)
switch (ch) {
case '0': case '1': case '2': case '3': case '4':
case '5': case '6': case '7': case '8': case '9':
***
*** 114,123
--- 118,134
ifd = 0;
break;
case 'a': /* Suffix length */
+ if (Bflag)
+ errx(EX_USAGE, -a is incompatible with -B);
if ((sufflen = strtol(optarg, ep, 10)) = 0 || *ep)
errx(EX_USAGE,
%s: illegal suffix length, optarg);
break;
+ case 'B': /* Byte count compute sufflen. */
+ if (sufflen != -2)
+ errx(EX_USAGE, -B is incompatible with -a);
+ Bflag = 1;
+ /* fall through */
case 'b': /* Byte count. */
errno = 0;
if ((bytecnti = strtoimax(optarg, ep, 10)) = 0 ||
***
*** 153,164
--- 164,185
argv += optind;
argc -= optind;
+ if (sufflen == -2)
+ sufflen = 2;
+
if (*argv != NULL)
if (ifd == -1) {/* Input file. */
if (strcmp(*argv, -) == 0)
ifd = STDIN_FILENO;
else if ((ifd
Re: Geode SC1100 i2c bus
The ACB is at the same level than Uart, so I had a look at sio source and got a big headache. I'm not really used to drivers nor kernel programming stuff, that's why I need your help. Why do you compare ACB and UART? In FreeBSD, sio is serial i/o controller, not superIO, maybe you are confused... ACB and UART does not have much in common... As I read the OP, both the ACB and the serial are in the same chip (the superIO), so it would seem reasonable to expect that the method of accessing the device registers in the (currently unsupported) ACB might be similar to the method of accessing the device registers in the (supported) serial port. Note I said reasonable -- it may not be accurate -- and this sort of analysis applies only to getting at the hardware. Certainly the means of communicating with the rest of the OS would be different, unless one wants the ACB to show up as sio7 or some such :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
I'd like to see the ability to run gjournal without reformatting. If you could create a dummy file inside the filesystem, then use that area for the journal, it might be possible ... I am not sure about gjournal internals but what if a system crash occurs in the middle of a transaction and the fs gets corrupted and the data, necessary to fix it is in the journal, but you cannot access the journal because the file, which contains the journal, is on a corrupted fs? Looking at this as purely a data-integrity problem, and knowing nothing whatsoever about gjournal internals :) I would guess that if a way could be found to preallocate the journal space (as with mkfile(8) in sufficiently-old systems), and then record its location in a reasonably-secure location (the superblock?), it could be accessed during recovery without reference to possibly-corrupt filesystem metadata. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump reads more than restore writes?
Is dump reading substantially more than restore is writing? Quite possibly, esp. if the source disk is nowhere near full and/or most of the files being handled are small. dump reads every inode on the disk, including those which are unallocated, and probably reads entire data blocks -- or even entire FS blocks -- even when only part of the block contains useful data. Restore writes only what it has to. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ufs_rename: fvp == tvp (can't happen), but it did
The problem is the following: on machine A the mail spool is on a local disk array (via ciss). On machine B we run experiments with an FC disk array, so the e-mails are on gmirror'ed filesystems (on ciss for the local disks and on isp for the FC array). The strange thing happens when both the local and FC disks are working in the mirrors. I get the following warning very often: ufs_rename: fvp == tvp (can't happen) If I do a gmirror remove for the FC array, these go away. Also, the other machine (with only local disks) is free from this. It sounds as if the caller of ufs_rename() is confused. You could try setting a breakpoint on the printf(), or change it to a panic() to get a dump, and try to figure out who the caller is and what is going on. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to deal with const
If you need strstr(3) in your project is allready defined in libkern. The implementation is identical, but using the __DECONST macro. Take a look in /usr/src/sys/libkern/strstr.c for the function definition and /usr/src/sys/geom/label/g_label.c for usage. The function prototype is defined in sys/libkern.h There's no strstr.c in my (6.1) libkern, but sys/cdefs.h does provide __DECONST and it certainly looks like the intended solution. Thanks for the pointer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
how to stop the automatic reboot
Pressing a key after the Automatic reboot in 15 seconds - press a key on the console to abort message does not seem to prevent the reboot. What is the correct way of stopping it long enough to copy the other messages? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
how to deal with const
I'm working on a kernel project that needs strstr(3).
It looks as if most of the str* functions in libkern are very
similar, if not identical, to their counterparts in libc/string,
but that approach does not seem to work for strstr (#s added):
1: char *
2: strstr(s, find)
3: const char *s, *find;
4: {
5: char c, sc;
6: size_t len;
7:
8: if ((c = *find++) != 0) {
9: len = strlen(find);
10: do {
11: do {
12: if ((sc = *s++) == 0)
13: return (NULL);
14: } while (sc != c);
15: } while (strncmp(s, find, len) != 0);
16: s--;
17: }
18: return ((char *)s);
19: }
I get a warning: cast discards qualifiers from pointer target type
on line 18. If I remove the cast, changing it to just return (s);,
I get warning: return discards qualifiers from pointer target type
(and because this is the kernel, those warning messages are actually
treated as errors).
What is the accepted method of dealing with this sort of thing?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Example network protocol implementation
Vishal Patil [EMAIL PROTECTED] wrote: Could someone point me to an example that shows a SIMPLE network protocol implemented over TCP/IP inside the FreeBSD kernel. I think I could look at the NFS client driver but is there an example simpler than that. NFS normally runs over UDP, not TCP. Telnet is one of the simpler TCP-based applications, but it is not done in the kernel (nor are most network apps). Is there some particular reason why you need an example that is implemented inside the kernel, vs in userland? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] rm can have undesired side-effects
IMHO many problems arise when someone tries to please even the stupidest user by writing a fool-proof software. To me the beauty of Unixes is that they are _not_ fool-proof, e.g. your are holding a real gun, you should be carefull not to point it to your head and pull the trigger. If we wanted to follow that line of reasoning to its logical conclusion, I think we would have to make -f the default behavior for rm, which BTW is how it worked in ATT 6th Edition. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] rm can have undesired side-effects
... deleted files are lost. Not if another hard link exists! I think a very strong case can be made that the *intent* of -P -- to prevent retrieval of the contents by reading the filesystem's free space -- implies that it should affect only the real removal of the file, when its blocks are released because the link count has become zero. At that point, we by definition are only wiping out data which is eligible to be overwritten by any process that happens to be allocating space on the same filesystem, and which can no longer be read by normal filesystem operations, anyway. In this interpretation, rm -P when the link count exceeds 1 is an erroneous command. I'd at least allow rm -P to wipe a file with a non-zero remaining link count only under the same restrictions applied to files that are not writable by the invoker of rm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic caused by bad memory?
I can't get a kernel dump since it fails like this each time: dumping to dev #da/0x20001, offset 2097152 dump 1024 1023 1022 1021 Aborting dump due to I/O error. status == 0xb, scsi status == 0x0 failed, reason: i/o error Bad memory seems unlikely to cause an I/O error trying to write the dump to the swap partition. I'd guess a dicey drive -- and bad swap space could also account for the original crash. You might be able to get a backup by booting single user, provided nothing activates the (presumably bad) swap partition. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
