Re: Size-independent byte order swapping functions.
David Schultz writes: I'm not sure if dedicated epanic() is the best way to implement out-of-rang e errors prevention - the more handy solution should cause compile error. See CTASSERT. There is an extremely limited number of sizes that are possible here, even with weird/theoretical architectures like 256-bit machines. Doesn't it make sense just to presume that out-of-range is impossible, and recode for default if (sizeof(x) == 1) return x; (ignore syntax) ? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Size-independent byte order swapping functions.
On Mon, Nov 24, 2003 at 05:13:08PM -0800, David Schultz wrote: + On Mon, Nov 24, 2003, Pawel Jakub Dawidek wrote: + If one is using strictly defined types as uint8_t, uint16_t, int32_t, etc. + those macros are helpful IMHO, because futher value size changes does not + affects code for byte order managing. This also does not hit perfromance, + because this should be resolved at compile-time. + + Cool, looks useful. + + I'm not sure if dedicated epanic() is the best way to implement out-of-range + errors prevention - the more handy solution should cause compile error. + + See CTASSERT. I've tried, but you can't use CTASSERT() inside (?:). -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: using devel/libusb to access USB
On Mon, Nov 24 2003 (09:25:52 -0500), Dan Langille wrote: We have been looking at the devel/libusb port and experimenting with testlibusb which is a part of that port. We have noticed that usb_find_devices() does not find any devices. Looking at the usb.c code within libusb, we found that usb_os_find_devices() does not return any devices, and therefore the while loop is never entered. We tracked the problem down to usb_os_find_devices() (within bsd.c) and found that various things were preventing the list from being created. I have experienced a similar problem a few months ago. I've tracked it to ugenopen() in sys/dev/usb/ugen.c, which returned EBUSY if the control endpoint /dev/ugen0 was already open. Consequently, usb_find_devices() failed to return anything useful. However, as Bernd Walter suggested in a recent posting to hackers@, this could be avoided by using interface specific endpoints (/dev/ugen?.?) instead of the control endpoint (/dev/ugen?) for communication. Cheers, Toni ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making a FreeBSD DVD
On Sun, Nov 23, 2003 at 09:28:37PM -0500, Leo Bicknell wrote: I'd like to make my own distribution DVD's. I know how to make CD's, but looking at release(7) I see lots of documentation for CD's, and none for DVD's. Googling turns up nothing of interest in the first three pages. Can anyone point me to the documentation on how to build DVD's, a-la what they sell on FreeBSD mall? Do you mean one offs, using a DVD burner, or do you mean in bulk, using a DVD replication house? If it's the former, ports/sysutils/dvd+rw-tools. If it's the latter, ports/sysutils/dvdtape. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) pgp0.pgp Description: PGP signature
freebsd smp - linux up
is there a way to have linux emulation report that its kernel is running on a UP system even though the freebsd box it's running on is SMP? i would like to get vmware running on my smp -current box, but vmmon_smp.ko is broken, and with vmmon_up.ko loaded i get a message about needing to be running on an smp linux kernel version 2.0 (2.2) or higher, even though linux emulation reports a 2.4 kernel. my hope is that having vmware make no attempt at using smp resources i can get it to start. thanks for any help. -Anthony. from sysctl compat.linux: compat.linux.osname: Linux compat.linux.osrelease: 2.4.2 compat.linux.oss_version: 198144 pgp0.pgp Description: PGP signature
Re: integer and long max/min values
On Fri, 21 Nov 2003, Duane H. Hesser wrote: On 21-Nov-2003 Richard Coleman wrote: Jay Sern Liew wrote: how do I find out the maximum (and minimum) value a long and int will hold in C? (before it overflows or underflows) if it's compiler-dependent, then does anyone know where I can find the GCC documentation for stuff like that? It will be architecture dependent (32 or 64 bit machines?). I doubt the GCC docs talk about this. You might check Richard Steven's book on Advanced Unix Programming. It covers lots of information about standard machine limits and how to discover them. As a point of interest, there is a file /usr/src/contrib/gcc/enquire.c in the distributed sources which, when compiled and run, will report the max and min values of short, long, int, float, etc. along with various sizes and alignments. To get the latest version (5.1a) of enquire: http://homepages.cwi.nl/~steven/enquire.html Sean --- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd smp - linux up
Anthony Schneider [EMAIL PROTECTED] writes: is there a way to have linux emulation report that its kernel is running on a UP system even though the freebsd box it's running on is SMP? i would like to get vmware running on my smp -current box, but vmmon_smp.ko is broken, and with vmmon_up.ko loaded i get a message about needing to be running on an smp linux kernel version 2.0 (2.2) or higher, even though linux emulation reports a 2.4 kernel. It would be interesting to know exactly what it needs that we don't provide. I suspect it's something really trivial... do you see any messages in syslog about unimplemented syscalls? Could you get a ktrace or something? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Pictures from the big BSD Party bash are up.
The pictures from the big BSD party bash last night are up. There were a lot of people there... at least 200. It was a lot of fun! But if you missed out you can console yourself with the pics: http://apollo.backplane.com/pics.bsdparty/ -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
patchlevels and FreeBSD source
Hi all, Presently I install my servers using a automated pxeboot method. The NFS image I choose is a copy of the freebsd 4.8-RELEASE cdrom. Post install I cvsup the plain 4.8-RELEASE server to RELENG_4_8 (taking the patchlevel to 4.8-RELEASE-p15 for example) and then build world. The cvsup/buildworld takes a long time. These steps are also difficult to automate. My question is: Is it possible that I update my cdrom image to the to 4.8-RELEASE-p15 before install ? In other words, are the patches that released as source diffs also available as downloadable cd images? If the answer is no, then can I patch the cdrom image myself or create a new PATCHED cd image that I can then use for my NFS installs ? Thanks for your replies. Regards, -ansh mail2web - Check your email from the web at http://mail2web.com/ . ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
Wes Peters wrote: On Tuesday 18 November 2003 16:31, Rayson Ho wrote: e.g. when deleting a secure file, the OS will overwrite the file with random data. Better to overwrite it with a more secure pattern. See ports/ sysutils/obliterate for references. It has been mentioned before that this could be done on in the kernel, obliterating blocks in the VM rather than zeroing them. I hadn't thought of applying at the file or filesystem level. The DOD has a specific pattern it requirs, to consider the deletion to be secure. The closest we have is the 'rm -P' command and the above-mentioned obliterate command. The overwrite pattern used in 'rm -P' is not likely to be effective against a dedicated inspection of the disk; the one in obliterate somewhat more so. On most modern drives, nothing is likly to be ffective, without OS support all th way down to the driver and hardware flags level. The DOD specified pattern is only effective if you have separate control of the seek and the write. The reason for this is that you musttake head hysteresis into account since if you did a seek in for the initial write and a seek out for the erase, you will ens up with a small strip of bits that are readable, even if they are much smaller than a standard track width, since there is jitter in the head positioning that depends on the side of the track you are coming from. So in reality, you also need to control sector sparing and write caching, as well, to avoid track caching, if possible, and seeks for sector sparing which are hidden from the OS trying to invoke the write pattern: you need to turn both of these off, if you can. If you can't, you need to buy a different disk, and turn both of these off, if you can. If you can't, you are going to ned to write your own disk firmware. You also need to deal with not writing to tracks at one end or the other of the disk, since you can't seek to them from the opposite direction, which means you have no way to write the pattern you are expected to write. This generally means that the end tracks need to be treated as scrath landing zones, and you only ever write pattern data to them, and then only because that's the way to get the disk head onto the track so you can seek back to the track that you really want to erase. In a track-caching world, this tends to be not useful, unless you can determine the physical geometry of the disk, and treat tracks as separate entities. Finally, if you have a track-caching disk, it's likely that the way it operates is to just seek in and start writing. That will mean that in order to avoid a thin stripe of your old bits, you have to trat tracks as singl entities, and that means that if you have a track that shares data with several files, and you want to scribble over one of them effectively, you have to scribble over everything effectively, and then put the data for the filec(s) you didn't want to erase back on the track. This sounds like an interesting file flag. Would you expect the process to block on the unlink(2) call while the overwrite takes place, or for this to happen in a kernel thread? The former seems pretty straight- forward, hacking at ffs_blkfree. The latter I really wouldn't know how to begin without (a lot) more study. You would have to do the former, or you would not pass common criteria valuation, if that's what you are aiming for. The normal way this is handled in government secure facilities is a 2U rack unit containing thermite charges. The normal way this is handled in a commercial scure facility is mostly to put the disks in a crusher. If this is somthing other than that, I doubt anyone would be willing to spend US$60,000/MB to have someone recover your porn. You are likely safe enough with PHK's somewhat inscure disk encryption thingy. As an overall note, you might want to contact Michal Serrachio off list; he has a solution to this problem which h might be willing to license to you for a fee. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
getpwnam with md5 encrypted passwds
Hi,
i am trying to validate a given user password against my local passwd-file with
this piece of code :
if (!( pwd = getpwnam ( user ))) {
log(ERROR,User %s not known,user);
stat=NOUSER;
}
if (!strcmp( crypt(pass,pwd-pw_name), pwd-pw_passwd) ) {
log(DEBUG|MISC,HURRAY : %s authenticated\n, user);
stat = AUTHED;
}
The problem is, that my passwords are encrypted in md5-format, so the strcmp
fails always. Now i did not find any usable information on how to work this out
on FreeBSD, and how to be independent from the settings in the login-conf ?
(that i dont have to check whether its using crypt,md5 or blowfish)
The code should be running on 4.x and 5.x
Any ideas ?
Kind regards
Kai
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Library libgcc_pic.a missing on 5.1?
Jim Durham wrote: Is liibgcc_a not supposed to be on 5.1? Is the one in /usr/lib not good enough for you? 8-) 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
puc/sio driver - receives but doesn't send
Hi, I just got a Syba 2 port serial I/O card, from dmesg: puc0: NetMos NM9835 Dual UART and 1284 Printer port port 0x7000-0x700f,0x7400-0x7407,0x7800-0x7807,0x8000-0x8007,0x8400-0x8407,0x8800-0x8807 irq 5 at device 15.0 on pci0 sio2: type 16550A sio3: type 16550A The above dmesg line is not 100% correct - the card does not have a parallel port, just 2 serial ports. Using either of the available 2 ports, I'm able to receive data, but it doesn't want to transmit. I've tried everything I can think of, which includes: * both with and without the PUC_FASTINTR kernel option * ensure flow control lines are correct / ignored * using a loopback handshake cable (just in case) If I hook one of the SIO ports on the PUC to one of the serial ports on the motherboard, and open 'tip' on each one, what I type on the motherboard serial gets displayed on the PUC serial port tip session. However, when I type in the PUC serial port tip window, no data comes though on the motherboard serial tip. But when I run systat, I can see the puc0 device getting interrupts on irq 5 when I'm typing characters, as if it is sending the characters. Also, I have verified with a seperate microcontroller serial device - the PUC port is receiving data fine from the microcontroller, but it is not sending to the microcontroller for some reason. Anybody have any ideas what might be wrong? And yes, the motherboard serial ports both work as expected using the same cables, etc. I'm running 4.9-STABLE from a few days ago. Thanks, -Brian -- Brian Dean [EMAIL PROTECTED] http://www.bsdhome.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: puc/sio driver - receives but doesn't send
In message: [EMAIL PROTECTED] Brian Dean [EMAIL PROTECTED] writes: : Anybody have any ideas what might be wrong? : : And yes, the motherboard serial ports both work as expected using the : same cables, etc. I know this is a long shot But maybe there's a cold solder joint on the NetMOS dual UART board? /me happily using two PUC devices right now on his 4.9 box: puc0: Moxa Technologies, C168H/PCI port 0xa400-0xa40f,0xa800-0xa83f,0xb000-0xb07f irq 5 at device 9.0 on pci0 puc1: Titan PCI-800H port 0x9800-0x981f,0xa000-0xa01f mem 0xe100-0xe1000fff,0xe180-0xe1800fff irq 12 at device 10.0 on pci0 The moxa is a 8 port monster, and the Titan is a 4 port monster (yes, I do need 12 serial ports for all the machines I act as serial console for, well maybe only 10). Maybe I have too many machines... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
