Is there virtualbox ports?
Hi,all: I am ready to intall sun xVM VirtualBox on my FreeBSD7.0,but have no found in the ports,anybody can help me? -- Boern Parx ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is there virtualbox ports?
On Fri, Oct 31, 2008 at 7:23 AM, Boern [EMAIL PROTECTED] wrote: Hi,all: I am ready to intall sun xVM VirtualBox on my FreeBSD7.0,but have no found in the ports,anybody can help me? There is no port. VirtualBox depends on a kernel module that was not ported to FreeBSD yet, among other things. There was some discussion on the -virtualization mailing list. Take a look at the VirtualBox looks for FreeBSD developer thread in http://lists.freebsd.org/pipermail/freebsd-virtualization/2008-September/thread.html http://lists.freebsd.org/pipermail/freebsd-virtualization/2008-October/thread.html -- cd /usr/ports/sysutils/life make clean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open(2) and O_NOATIME
2008/10/31 Jeremy Chadwick [EMAIL PROTECTED]: ... If that's what you were referring to, then possibly making O_NOATIME only to root would be a suitable compromise. And no systems are compromised with rootkits?.. Igor :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is there virtualbox ports?
Quoting Boern [EMAIL PROTECTED]: Hi,all: I am ready to intall sun xVM VirtualBox on my FreeBSD7.0,but have no found in the ports,anybody can help me? VirtualBox doesn't work on FreeBSD... pgpOXLlePpZcx.pgp Description: Digitale PGP-Unterschrift
Re: memtest86+ can not link: binutils issue?
on 30/10/2008 20:46 Peter Jeremy said the following: On 2008-Oct-30 18:08:35 +0200, Andriy Gapon [EMAIL PROTECTED] wrote: 1. obtain and extract http://www.memtest.org/download/2.01/memtest86+-2.01.bin.gz This is a compressed bootable image and can't be compiled. Possibly you mean http://www.memtest.org/download/2.01/memtest86+-2.01.tar.gz Sorry - yes, this was it. 2. run gmake: $ gmake gcc -E -traditional head.S -o head.s as -32 -o head.o head.s gcc -c -Wall -march=i486 -m32 -Os -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -fno-strict-aliasing reloc.c gcc -Wall -march=i486 -m32 -Os -fomit-frame-pointer -fno-builtin -ffreestanding -fPIC -c -o main.o main.c gcc -c -Wall -march=i486 -m32 -Os -fomit-frame-pointer -fno-builtin -ffreestanding test.c Blows up at this point for me: gcc -c -Wall -march=i486 -m32 -Os -fomit-frame-pointer -fno-builtin -ffreestanding test.c test.c:14:20: error: sys/io.h: No such file or directory test.c: In function 'beep': test.c:1410: warning: implicit declaration of function 'outb_p' test.c:1410: warning: implicit declaration of function 'inb_p' test.c:1417: warning: implicit declaration of function 'outb' gmake: *** [test.o] Error 1 I can't find sys/io.h in CVS or any declarations for outb_p or inb_p in my source tree. Sorry again - I patched this file to remove inclusion of this linux-specific file and instead include machine/cpufunc.h, also I changed outb_p = outb, inb_p = inb and swapped parameters of outb-s. These are typical linuxisms. ld --warn-constructors --warn-common -static -T memtest_shared.lds \ -o memtest_shared head.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o config.o linuxbios.o memsize.o pci.o controller.o random.o extra.o spd.o error.o dmi.o \ ld -shared -Bsymbolic -T memtest_shared.lds -o memtest_shared head.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o config.o linuxbios.o memsize.o pci.o controller.o random.o extra.o spd.o error.o dmi.o head.o(.text+0x7): In function `startup_32': : undefined reference to `_GLOBAL_OFFSET_TABLE_' Segmentation fault (core dumped) gmake: *** [memtest_shared] Error 139 I can't help here. _GLOBAL_OFFSET_TABLE_ is related to the binutils PIC support and it appears that the linker doesn't like the code (in head.S) is explicitly referencing it. Not only linking fails, but ld even crashes. I agree this shouldn't happen. Can anybody suggest anything about this problem? It looks like stand-alone PIC code on FreeBSD needs some different incantations to Linux. My understanding is that several of the i386 bootstraps are relocatable so you might like to peruse the code in /usr/src/sys/boot/i386 for ideas. I wonder if this is something about out port of binutils or is it an issue in older version of binutils. I'll try to look at the boot code, thank you for the hint. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open(2) and O_NOATIME
On Fri, Oct 31, 2008 at 08:04:48AM +, Igor Mozolevsky wrote: 2008/10/31 Jeremy Chadwick [EMAIL PROTECTED]: ... If that's what you were referring to, then possibly making O_NOATIME only to root would be a suitable compromise. And no systems are compromised with rootkits?.. utimes(2) allows non-root users to (re)set atime provided they own the file or have write permission. Having O_NOATIME follow the same rules would not break any assumed security any further than utimes(2) already does but greatfully benefit all kind of backup programs. So I'd be more than happy to see O_NOATIME be implemented as I'm currently experimenting with backups to detachable harddisks using rsync and not having a way to reset atime is my one big reason for not deploying this kind of backups with more servers. If you wonder why I'm using rsyng instead of dump or tar, here are two reasons: first the detachable disks are much slower than the systems disks so rsync saves a lot of time and secondly a file-by-file-only-if-changed scheme allows me to efficiently use snapshots on the backup medium. Patching rsync to implement the kind of reset atime as i.e. cpio does looks far more complex than adding O_NOATIME to rsync. My $0.02 Regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open(2) and O_NOATIME
On Fri, Oct 31, 2008 at 02:48:42PM +0100, Paul Schenkeveld wrote: utimes(2) allows non-root users to (re)set atime provided they own the file or have write permission. Having O_NOATIME follow the same rules would not break any assumed security any further than utimes(2) already does but greatfully benefit all kind of backup programs. This is not entirely correct. utimes(2) with NULL timestamps (reset atime and mtime to current time) is allowed to root, owner or with write permission, but utimes(2) with given timestamps is only allowed to root and owner. O_NOATIME seems equivalent to the latter, and in fact this is the case in Linux (if someone else than root or the owner tries to open a file with O_NOATIME, they get EPERM). There's only a small detail missing: any utimes(2) call updates the ctime, so you can see something happened to the file. Linux's O_NOATIME does not update any times at all (this speeds up things). Anyway, O_NOATIME (only for root/owner) seems a useful feature. -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
strange behaviour with /sbin/init and serial console
Hello,
with the following patch on /sbin/init, I have two different behaviours
depending on the console type (on a i386/32 PC) :
- on a video console, I see the expected two messages,
- on a serial console, the messages are not displayed (init silently finishes
its job and gets to start /etc/rc and everything)
I assume that the writev system call is implemented in
src/sys/kern/tty_cons.c::cnwrite(), but I could not parse the code to find an
explanation.
any taker ?
TfH
PS : this is initially for a RELENG_6 machine, but the code is quite similar
under RELENG_7 or Current
--- usr/src/sbin/init/init.c.ori2008-10-31 14:20:48.294794898 +0100
+++ usr/src/sbin/init/init.c2008-10-31 14:12:16.168062031 +0100
@@ -44,6 +44,8 @@
$FreeBSD: src/sbin/init/init.c,v 1.60.2.2 2006/07/08 15:34:27 kib Exp $;
#endif /* not lint */
+#include sys/types.h
+
#include sys/param.h
#include sys/ioctl.h
#include sys/mount.h
@@ -239,6 +241,23 @@
*/
openlog(init, LOG_CONS|LOG_ODELAY, LOG_AUTH);
+ warning(warning after openlog);
+{
+int fd;
+ if ((fd = open(/dev/console, O_WRONLY|O_NONBLOCK, 0)) = 0) {
+ struct iovec iov[2];
+ struct iovec *v = iov;
+
+ v-iov_base = (void *)iov direct write test;
+ v-iov_len = 21;
+ ++v;
+ v-iov_base = (void *)\r\n;
+ v-iov_len = 2;
+ (void)writev(fd, iov, 2);
+ (void)close(fd);
+ }
+
+}
/*
* Create an initial session.
*/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: memtest86+ can not link: binutils issue?
On Fri, 31 Oct 2008, Andriy Gapon wrote: on 30/10/2008 20:46 Peter Jeremy said the following: On 2008-Oct-30 18:08:35 +0200, Andriy Gapon [EMAIL PROTECTED] wrote: ld --warn-constructors --warn-common -static -T memtest_shared.lds \ -o memtest_shared head.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o config.o linuxbios.o memsize.o pci.o controller.o random.o extra.o spd.o error.o dmi.o \ ld -shared -Bsymbolic -T memtest_shared.lds -o memtest_shared head.o reloc.o main.o test.o init.o lib.o patn.o screen_buffer.o config.o linuxbios.o memsize.o pci.o controller.o random.o extra.o spd.o error.o dmi.o head.o(.text+0x7): In function `startup_32': : undefined reference to `_GLOBAL_OFFSET_TABLE_' Segmentation fault (core dumped) gmake: *** [memtest_shared] Error 139 I can't help here. _GLOBAL_OFFSET_TABLE_ is related to the binutils PIC support and it appears that the linker doesn't like the code (in head.S) is explicitly referencing it. Not only linking fails, but ld even crashes. I agree this shouldn't happen. Can anybody suggest anything about this problem? It looks like stand-alone PIC code on FreeBSD needs some different incantations to Linux. My understanding is that several of the i386 bootstraps are relocatable so you might like to peruse the code in /usr/src/sys/boot/i386 for ideas. I wonder if this is something about out port of binutils or is it an issue in older version of binutils. I'll try to look at the boot code, thank you for the hint. FreeBSD's version of binutils is quite old. I've definitely found bugs in it which are fixed in GNU's current version. So you might try building the official GNU binutils and see if that works any better. I don't know if it will fix your error but maybe it at least won't crash. ld crashing is definitely a bug, and it would be nice if you could file a PR, including the object files. If the GNU version doesn't crash that would be useful information for the PR also, as it might encourage Them to consider importing a newer version. -- Nate Eldredge [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: strange behaviour with /sbin/init and serial console
On Fri, Oct 31, 2008 at 05:46:23PM +0100, Thierry Herbelot wrote: with the following patch on /sbin/init, I have two different behaviours depending on the console type (on a i386/32 PC) : - on a video console, I see the expected two messages, - on a serial console, the messages are not displayed (init silently finishes its job and gets to start /etc/rc and everything) I thought this was normal behaviour on FreeBSD, but it's very likely I'm misunderstanding. The charts in Section 27.6.4 describe what level of logging is shown where and at what stage, depending upon which boot flags and device settings you use: http://www.freebsd.org/doc/en/books/handbook/serialconsole-setup.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange behaviour with /sbin/init and serial console
Le Friday 31 October 2008, Jeremy Chadwick a écrit : On Fri, Oct 31, 2008 at 05:46:23PM +0100, Thierry Herbelot wrote: with the following patch on /sbin/init, I have two different behaviours depending on the console type (on a i386/32 PC) : - on a video console, I see the expected two messages, - on a serial console, the messages are not displayed (init silently finishes its job and gets to start /etc/rc and everything) I thought this was normal behaviour on FreeBSD, but it's very likely I'm misunderstanding. The charts in Section 27.6.4 describe what level of logging is shown where and at what stage, depending upon which boot flags and device settings you use: http://www.freebsd.org/doc/en/books/handbook/serialconsole-setup.html Hello, I had not taken the time to read this link as thouroughly as should have been. nevertheless, I think the config is right, as the serial console is selected with -h in /boot.config (from memory, the machine is at work ...) and all *other* expected messages from the kernel (dmesg) and the rc scripts are correctly displayed on respectively the serial and video console. what struck me is that, from all the startup messages, just the messages from /sbin/init are displayed only on the video console TfH ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open(2) and O_NOATIME
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Schenkeveld wrote: [...] utimes(2) allows non-root users to (re)set atime provided they own the file or have write permission. Having O_NOATIME follow the same rules would not break any assumed security any further than utimes(2) already does but greatfully benefit all kind of backup programs. Yes this makes sense I think. Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkLR3AACgkQi+vbBBjt66BPhACfcZf6JcH0RmTpbpZHVXjdrJTq f7oAoLqQwb2UkFGrDDTy7//Ril2JWmA4 =y1zY -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
I believe someone has told me on this list that the proper way to compile a linux program is to run configure --includedir=/usr/local/include --libdir=/usr/local/lib. Is that correct? I've got a bunch of linux weenies trying to tell me their code isn't broken because I'm supposed to have headers where theirs are. They state that includedir is used by *their* project to locate it's *own* headers, so they never bothered to wire it up in Makefile.init gets ignored entirely. I figured I'd better know what I'm talking about before I tell someone they are 'wrong'. Especially as it's usually me ;) Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange behaviour with /sbin/init and serial console
Hello Theirry, * Thierry Herbelot [EMAIL PROTECTED] wrote: with the following patch on /sbin/init, I have two different behaviours depending on the console type (on a i386/32 PC) : - on a video console, I see the expected two messages, - on a serial console, the messages are not displayed (init silently finishes its job and gets to start /etc/rc and everything) I assume that the writev system call is implemented in src/sys/kern/tty_cons.c::cnwrite(), but I could not parse the code to find an explanation. any taker ? TfH PS : this is initially for a RELENG_6 machine, but the code is quite similar under RELENG_7 or Current Any data written to /dev/console is not multiplexed to all console devices, but only the first active device in the list. The reason behind this, is because it adds a real lot of complexity to the console code, especially related to polling and reading on /dev/console. This weekend I'm going to commit a replacement implementation of /dev/console, which also has this restriction. -- Ed Schouten [EMAIL PROTECTED] WWW: http://80386.nl/ pgpF88ru0nCzf.pgp Description: PGP signature
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Fri, Oct 31, 2008 at 12:11 PM, Nate Eldredge [EMAIL PROTECTED] wrote: On Fri, 31 Oct 2008, Steve Franks wrote: I believe someone has told me on this list that the proper way to compile a linux program is to run configure --includedir=/usr/local/include --libdir=/usr/local/lib. Nitpick: not specifically a Linux program, but a program using a configure script generated by GNU's autoconf system. Programs using autoconf may run on systems other than Linux (usually do, in fact, since the point of autoconf is portability), and many Linux programs don't use autoconf. And I'll assume that by 'linux' you actually mean FreeBSD, in order for this to be on-topic for this list :) Is that correct? I've got a bunch of linux weenies trying to tell me their code isn't broken because I'm supposed to have headers where theirs are. I don't understand this sentence. They state that includedir is used by *their* project to locate it's *own* headers, so they never bothered to wire it up in Makefile.init gets ignored entirely. I figured I'd better know what I'm talking about before I tell someone they are 'wrong'. Especially as it's usually me ;) It looks to me like both of you are wrong. :) Looking at the configure that comes with wget-1.11.2, running configure --help says Fine tuning of the installation directories: ... --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] So it looks like --libdir is supposed to specify where libraries are to be *installed*, not where they are to be searched for. Further up in the help we have --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] So libraries would already be installed in /usr/local/lib by default, unless you used a --prefix or --exec-prefix option to override that. Similarly for include files. If you need the program being built to search for libraries or include files in a certain place (such as /usr/local/include and /usr/local/lib, which are not searched by default on FreeBSD), AFAIK the right way to do it is to set the LIBRARY_PATH and C_INCLUDE_PATH (or CPLUS_INCLUDE_PATH) environment variables. -- Nate Eldredge [EMAIL PROTECTED] Let's backup. What's the 'right' way to get a bloody linux program that expects all it's headers in /usr/include to compile on freebsd where all the headers are in /usr/local/include? That's all I'm really asking. Specifically, it's looking for libusb libftdi. If I just type gmake, it can't find it, but if I manually edit the Makefiles to add -I/usr/local/include, it can. Obviously, manually editing the makefiles is *not* the right way to fix it (plus it's driving me crazy). Steve Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Fri, 31 Oct 2008, Steve Franks wrote: Let's backup. What's the 'right' way to get a bloody linux program that expects all it's headers in /usr/include to compile on freebsd where all the headers are in /usr/local/include? That's all I'm really asking. Specifically, it's looking for libusb libftdi. If I just type gmake, it can't find it, but if I manually edit the Makefiles to add -I/usr/local/include, it can. Obviously, manually editing the makefiles is *not* the right way to fix it (plus it's driving me crazy). C_INCLUDE_PATH=$C_INCLUDE_PATH:/usr/local/include LIBRARY_PATH=$LIBRARY_PATH:/usr/local/lib export C_INCLUDE_PATH LIBRARY_PATH ./configure gmake Adjust as appropriate if using csh. Personally, I set those environment variables in my .profile. By the way, I think you're being a little unfair to blame this on Linux programs or programmers. Normally it's the user's responsibility to ensure that their compiler searches for include files, etc, in the appropriate place. Many Linux distributions put everything in /usr/include, which is searched by default. FreeBSD puts stuff from ports in /usr/local/include which isn't searched by default. I find that behavior inconvenient, which is why I set those environment variables, so I don't have to think about it. -- Nate Eldredge [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: strange behaviour with /sbin/init and serial console
* Scott Long [EMAIL PROTECTED] wrote: The multiplexed console feature is one thing that linux got right. In a corporate setting, you really need both a serial console and a video console in order to effectively manage the machines, as you want to be able to access them both remotely and locally. While it might be hard to build multiplexing into the console driver, do you think it would be possible to layer a multiplexer on top of it, similar to how the kbdmux driver works? I'm not sure at which level we should implement this. I mainly wrote the new /dev/console implementation, because it is a lot more simple than the existing one and removes ugly hacks from the TTY code (like recursive locking, etc). Maybe if I can find some more time I'll look into it more closely, but my todo list is very long right now. ;-) -- Ed Schouten [EMAIL PROTECTED] WWW: http://80386.nl/ pgpvX4JmlJp7z.pgp Description: PGP signature
Re: strange behaviour with /sbin/init and serial console
Ed Schouten wrote: Hello Theirry, * Thierry Herbelot [EMAIL PROTECTED] wrote: with the following patch on /sbin/init, I have two different behaviours depending on the console type (on a i386/32 PC) : - on a video console, I see the expected two messages, - on a serial console, the messages are not displayed (init silently finishes its job and gets to start /etc/rc and everything) I assume that the writev system call is implemented in src/sys/kern/tty_cons.c::cnwrite(), but I could not parse the code to find an explanation. any taker ? TfH PS : this is initially for a RELENG_6 machine, but the code is quite similar under RELENG_7 or Current Any data written to /dev/console is not multiplexed to all console devices, but only the first active device in the list. The reason behind this, is because it adds a real lot of complexity to the console code, especially related to polling and reading on /dev/console. This weekend I'm going to commit a replacement implementation of /dev/console, which also has this restriction. The multiplexed console feature is one thing that linux got right. In a corporate setting, you really need both a serial console and a video console in order to effectively manage the machines, as you want to be able to access them both remotely and locally. While it might be hard to build multiplexing into the console driver, do you think it would be possible to layer a multiplexer on top of it, similar to how the kbdmux driver works? Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Fri, 31 Oct 2008, Nate Eldredge wrote: On Fri, 31 Oct 2008, Steve Franks wrote: Let's backup. What's the 'right' way to get a bloody linux program that expects all it's headers in /usr/include to compile on freebsd where all the headers are in /usr/local/include? That's all I'm really asking. Specifically, it's looking for libusb libftdi. If I just type gmake, it can't find it, but if I manually edit the Makefiles to add -I/usr/local/include, it can. Obviously, manually editing the makefiles is *not* the right way to fix it (plus it's driving me crazy). C_INCLUDE_PATH=$C_INCLUDE_PATH:/usr/local/include LIBRARY_PATH=$LIBRARY_PATH:/usr/local/lib export C_INCLUDE_PATH LIBRARY_PATH ./configure gmake Adjust as appropriate if using csh. Personally, I set those environment variables in my .profile. By the way, I think you're being a little unfair to blame this on Linux programs or programmers. Normally it's the user's responsibility to ensure that their compiler searches for include files, etc, in the appropriate place. Many Linux distributions put everything in /usr/include, which is searched by default. FreeBSD puts stuff from ports in /usr/local/include which isn't searched by default. I find that behavior inconvenient, which is why I set those environment variables, so I don't have to think about it. I don't really care who's to blame (I'd guess I'd blame both the Linux distros and the Linux application developers), but the move to put everything in /usr/include and /usr/lib annoys the heck out of me. It blurs the line between the base OS and installed 3rd party software. Perhaps that's because Linux is really just a kernel, and to the distributors - most, if not all, of their software is 3rd-party. It's really nice to be able to install 3rd-party software so that it doesn't affect the base OS. On FreeBSD, it's easy enough just to 'rm -rf /usr/local' and start fresh without having to worry about screwing up the base OS. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Friday 31 October 2008 20:30:46 Steve Franks wrote: Let's backup. What's the 'right' way to get a bloody linux program that expects all it's headers in /usr/include to compile on freebsd where all the headers are in /usr/local/include? That's all I'm really asking. Specifically, it's looking for libusb libftdi. If I just type gmake, it can't find it, but if I manually edit the Makefiles to add -I/usr/local/include, it can. Obviously, manually editing the makefiles is *not* the right way to fix it (plus it's driving me crazy). ./configure CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib They should consider using pkg-config in their configure script to locate libusb and libftdi. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange behaviour with /sbin/init and serial console
On Fri, Oct 31, 2008 at 01:28:02PM -0600, Scott Long wrote: Ed Schouten wrote: Hello Theirry, * Thierry Herbelot [EMAIL PROTECTED] wrote: with the following patch on /sbin/init, I have two different behaviours depending on the console type (on a i386/32 PC) : - on a video console, I see the expected two messages, - on a serial console, the messages are not displayed (init silently finishes its job and gets to start /etc/rc and everything) I assume that the writev system call is implemented in src/sys/kern/tty_cons.c::cnwrite(), but I could not parse the code to find an explanation. any taker ? TfH PS : this is initially for a RELENG_6 machine, but the code is quite similar under RELENG_7 or Current Any data written to /dev/console is not multiplexed to all console devices, but only the first active device in the list. The reason behind this, is because it adds a real lot of complexity to the console code, especially related to polling and reading on /dev/console. This weekend I'm going to commit a replacement implementation of /dev/console, which also has this restriction. The multiplexed console feature is one thing that linux got right. In a corporate setting, you really need both a serial console and a video console in order to effectively manage the machines, as you want to be able to access them both remotely and locally. I know this comment isn't much help, but, I am in full agreement with Scott. FreeBSD's lack of *true* multi (or even dual) console during all stages is a big disappointment to server administrators. The common reaction is: What do you mean I can only get some messages on serial or some messages on VGA?! That's retarded! I believe DragonFly has addressed this (offering a true dual console mechanism), and if I remember correctly, Matt Dillon discussed the code changes in great detail, citing a large amount of re-engineering required to accomplish it. While it might be hard to build multiplexing into the console driver, do you think it would be possible to layer a multiplexer on top of it, similar to how the kbdmux driver works? Let's make sure that we don't implement it identically though, as there are many of us who have major problems with kbdmux (reports of LORs, and even more reports of incredibly slow keyboard input when a USB keyboard is used; workarounds are either disabling atkbd/atkbdc entirely, or disabling kbdmux entirely. In my case, I found the latter to be preferable). :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
