Re: tgamma function in math library
On Fri, Jan 1, 2010 at 11:03 PM, Karthik Subramanian
karthik301...@gmail.com wrote:
On Fri, Jan 1, 2010 at 10:52 PM, Pierre Abbat p...@phma.optus.nu wrote:
I just copied one of my programming projects to the laptop and attempted to
compile it. The compiler bombed out on the line:
denom=tgamma(sh);
According to the man page for gamma on Linux:
*BSD version
4.4BSD and FreeBSD libm have a gamma() function that computes the Gamma
function, as one would expect.
glibc version
Glibc has a gamma() function that is equivalent to lgamma() and com‐
putes the natural logarithm of the Gamma function. (This is for com‐
patibility reasons only. Don’t use this function.)
How should I write the program so that it uses tgamma() on Linux and gamma()
on DragonFly?
Pierre
--
La sal en el mar es más que en la sangre.
Le sel dans la mer est plus que dans le sang.
Perhaps you could write a wrapper called gamma() that does something like
this:
=
struct utsname *ub;
/* malloc, etc. */
if(uname(ub)) {
die();
}
if (strcmp(ub-sysname, Linux) {
tgamma();
} else {
gamma();
}
=
You could also go the #ifdef LINUX route - in which case you need to
make sure to define LINUX
when compiling your code on linux.
There are probably better ways of doing this, I'll leave it to more
knowledgeable people on the list
to answer :)
K.
Sorry, forgot to mention - you might want to look at man 3 uname (on
DragonFly - on linux it's man 2 uname.).
K.
Trouble installing DragonFly under qemu-kvm
Hi Folks, I'm trying to install DragonFly under qemu, using an ISO (this one's yesterday's snapshot, I think). It boots fine, I'm able to login as root and everything seems to work OK. When I try to login as installer, however, I get the following error message: = Starting installer. Reading /etc/pfi.conf ... Unsupported DFUI transport '' . = It then logs me out. Does anybody know of a workaround? This is how I'm invoking qemu: qemu -m 512 -smp 1 -enable-kvm -net nic -net user -cdrom LATEST-i386-master.iso -hda ./df.img -boot d Thanks, Karthik.
Re: Trouble installing DragonFly under qemu-kvm
On Sun, Nov 8, 2009 at 4:05 PM, Sascha Wildner s...@online.de wrote: Karthik Subramanian schrieb: Hi Folks, I'm trying to install DragonFly under qemu, using an ISO (this one's yesterday's snapshot, I think). It boots fine, I'm able to login as root and everything seems to work OK. When I try to login as installer, however, I get the following error message: = Starting installer. Reading /etc/pfi.conf ... Unsupported DFUI transport '' . = It then logs me out. Does anybody know of a workaround? This is how I'm invoking qemu: qemu -m 512 -smp 1 -enable-kvm -net nic -net user -cdrom LATEST-i386-master.iso -hda ./df.img -boot d Can you login as root instead and check if the /etc/defaults/pfi.conf file is there? There was an issue on recent ISOs which caused them to not have this file. But it was fixed on the 5th. Thanks, Sascha. It turns out that the ISO that I was using is earlier than yesterday's snapshot. So yes, it doesn't have /etc/defaults/pfi.conf. I'll download today's snapshot and use that instead. Karthik.
Re: Trouble installing DragonFly under qemu-kvm
On Sun, Nov 8, 2009 at 4:26 PM, Karthik Subramanian karthik301...@gmail.com wrote: On Sun, Nov 8, 2009 at 4:05 PM, Sascha Wildner s...@online.de wrote: Karthik Subramanian schrieb: Hi Folks, I'm trying to install DragonFly under qemu, using an ISO (this one's yesterday's snapshot, I think). It boots fine, I'm able to login as root and everything seems to work OK. When I try to login as installer, however, I get the following error message: = Starting installer. Reading /etc/pfi.conf ... Unsupported DFUI transport '' . = It then logs me out. Does anybody know of a workaround? This is how I'm invoking qemu: qemu -m 512 -smp 1 -enable-kvm -net nic -net user -cdrom LATEST-i386-master.iso -hda ./df.img -boot d Can you login as root instead and check if the /etc/defaults/pfi.conf file is there? There was an issue on recent ISOs which caused them to not have this file. But it was fixed on the 5th. Thanks, Sascha. It turns out that the ISO that I was using is earlier than yesterday's snapshot. So yes, it doesn't have /etc/defaults/pfi.conf. I'll download today's snapshot and use that instead. Karthik. Today's snapshot worked! Thanks. Sascha. Karthik.
Re: USB Wireless
On Fri, May 22, 2009 at 12:09 PM, Sepherosa Ziehau sepher...@gmail.com wrote: On Fri, May 22, 2009 at 12:03 PM, Dylan Reinhold dy...@ocnetworking.com wrote: I'm trying to get my DF machine to connect via this Linksys Wireless-G USB device. The system sees it a generic USB device ugen0: Broadcom Linksys Wireless-G USB Network Adapter with SpeedBooster, class 2/0, rev 2.00/0.06, addr 2 on uhub0 Any ideas on how (and if) I can get this to work. There is no support for broadcom's usb wifi chips. Best Regards, sephe -- Live Free or Die Um, wouldn't it work with ndiswrapper? Ages ago I got a NetGear WG111 working on FreeBSD via ndiswrapper. I guess it should be possible to do this on DragonFly as well.
Re: LinkedIn DragonFly BSD group created
I tried to join the group, it says my membership is pending, that I've to contact you (Justin) for more information :) Karthik. On Tue, Jul 22, 2008 at 7:07 AM, Justin C. Sherrill [EMAIL PROTECTED] wrote: On Mon, July 21, 2008 9:03 pm, Matthew Dillon wrote: :For those of you who are using LinkedIn, I've created a DragonFly BSD :group.If you're interested, please join. There's nothing planned for :the group right now other than to populate it, but it may be useful in the :future for networking. Ok... I don't see an option to join a group through, only to create one. There's a search box on the upper right of the LinkedIn pages - select Groups from the drop-down and enter DragonFly BSD. There may be more graceful ways to find it, but I haven't discovered them. There's 18 members already - I was expecting maybe 5 or 7. That's neat! Now I wish I had a set purpose other than Hey, there should be a group for DragonFly for me and the two other people that mention it in their profiles.
Re: GSoC: LiveCD
On Tue, Jun 3, 2008 at 5:49 AM, Petr Janda [EMAIL PROTECTED] wrote: I think guys, we should use KDE 4.x for the GUI on the livecd. Petr +1 for KDE 4.x K.
Fwd: Porting Hammerfs (was: iSCSI, lvm, storage and the future)
Great News! Other folks are interested in Hammerfs too :) (apologies for the possible top-post, but I couldn't help it here). K. -- Forwarded message -- From: Mark Weinem [EMAIL PROTECTED] Date: Dec 10, 2007 8:46 AM Subject: Porting Hammerfs (was: iSCSI, lvm, storage and the future) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Hi Adam, we should try to port some really well documented fs e.g. Mathew Dillon Hammerfs ? Is it already well documented? I have the impression that it's still under heavy development. But it will surely be a great addition to NetBSD - please do it! Best regards, Mark (fup2 [EMAIL PROTECTED] set)
Re: Dumb question - loopback mounting an ISO image
On 9/9/07, Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: Justin C. Sherrill wrote: Would anyone object to this being present in GENERIC? It seems handy. vn is available as module cheers simon Muchas Gracias! I'll check this out later tonight. K.
Dumb question - loopback mounting an ISO image
Hi Guys, I have a dumb question - how do I loopback mount an ISO image in DragonFly? Thanks for your patience! K.
Re: KDE and OpenSSL = Broken
Oops. Wanted to reply to the list and ended up mailing the OP instead. Sorry, Kimura. === Hmmm. I downloaded dltest.c from the link you'd mentioned and tried this on my box: -- snip -- [EMAIL PROTECTED]: dltest $ gcc -L/usr/pkg/lib -lssl -o dltest dltest.c [EMAIL PROTECTED]: dltest $ ./dltest -- snip -- Seems to me there is nothing wrong with the lower layers. K.
Re: Release Schedule for 1.8
On 1/2/07, Justin C. Sherrill [EMAIL PROTECTED] wrote: On Tue, January 2, 2007 1:45 am, Karthik Subramanian wrote: Is there someplace where there's a list of release-oriented code bits/features, so that people can pick off stuff that they're interested in testing? I'm moving to a different city/state in a week or so, so i'm not sure if I can contribute to any testing right away - but I'd like to take a look all the same. That would be a good thing for the wiki. In fact, if you want to help out... I'd love to - but I'm going to be off the internet for around a couple of weeks starting Friday, and I'm not sure how much I can do before that :(
Re: help over rsync vs cvsupd perfmance
On 1/1/07, Saverio Iacovelli [EMAIL PROTECTED] wrote: Ok, I want to do a good test. So, I need some days yet, about one or two weeeks, the CVSup and rsync mirrors that I will test they are: 1) chlamydia.fs.ei.tum.de 2) AllBSD.org 3) TheShell.com My intention about test is the following: 1) I will test CVSup: - without and with compression of all data sent over network - without and with ssh connection to server 2) I will test rsync: - without and with compression of all data sent over network - without and with ssh connection to server Offhand, I think that both the compression and the encryption due to ssh would result in overheads we could do without. Personally, I'd be interested in raw cvsup vs. raw rsync :) But that's just my opinion, let that not stop you from finding out for yourself! BTW, Saverio - when you say you're testing rsync without ssh, I'm assuming that you'll be talking to the rsync daemon on the remote server - is that right? Have fun testing! Cheers, Karthik.
Re: help over rsync vs cvsupd perfmance
On 1/1/07, Saverio Iacovelli [EMAIL PROTECTED] wrote: 1) What meaning raw cvsup vs. raw rsync? 2) What is raw Um, I just meant cvsup vs. rsync without ssh. Rsync can talk to the rsync daemon that runs on the remote server, I'd think this is the best way that you can use rsync. I don't know enough about cvsup to say anything like that, though. For using ssh/rsh with rsync, you just need to do the following: rsync -e ssh/rsh other options And yes, probably the most important test is seeing how fast partial updates work, like Justin said. One other (not so important) thing you might want to try is to see what happens when you try to update say, 1.6 to 1.6 - ideally you should get a near-zero download. It'd be interesting to see how much data is actually transferred by cvsup and rsync. Hope this helps, K.
Re: Release Schedule for 1.8
:About testing, i think that we should start looking to do automated :regression testing of the system as much as we can. TET[1] looks like :a very good solution and FreeBSD is probably going to use it[2], so we :could get a lot of regression tests for free that apply to DragonFly. : :[1]: http://tetworks.opengroup.org/ :[2]: http://wikitest.freebsd.org/TetIntegration I dunno. I'm always skeptical about such frameworks and wonder whether porting them actually saves us any time over building our own. I do think testing will become a lot easier with the virtual kernel giving us a totally self contained environment for three files (kernel binary, memory image file, disk image file). Just my 2 cents as a guy who wrote part of a test framework ages ago :) I agree with Matt, rolling your own is the best way to go - simply because it's very difficult to get hold of something that does everything that you want, and does it well. Far better to write your own test framework in Python or the like, and get away with it. It doesn't take a long time, and it's worth the effort. Is there someplace where there's a list of release-oriented code bits/features, so that people can pick off stuff that they're interested in testing? I'm moving to a different city/state in a week or so, so i'm not sure if I can contribute to any testing right away - but I'd like to take a look all the same. Cheers, K.
Re: USB Pen drive
I'd be happy to help with further debugging if anyone wants help. Hi Folks, Sorry for the long absence, I'd been ill, and then had been busy with work. Unfortunately the friend of mine whose USB stick I'd been borrowing is out of circulation for some time, so I won't be able to debug with the stick for some more time :( Thanks a lot for all the help. Karthik.
struct dirent - difference between getdents(2) manpage and definition in /usr/src/sys/dirent.h
Hi Folks,
I was fooling around a little with getdents (yes, I know that I
shouldn't be using getdents!) and found that the getdents manpage
happened to say this about struct dirent:
-- snip --
The data in the buffer is a series of dirent structures each containing
the following entries:
u_int32_t d_fileno;
u_int16_t d_reclen;
u_int8_t d_type;
u_int8_t d_namlen;
chard_name[MAXNAMELEN + 1]; /* see below */
The d_fileno entry is a number which is unique for each distinct file in
the filesystem. Files that are linked by hard links (see link(2)) have
the same d_fileno. The d_reclen entry is the length, in bytes, of the
directory record.
-- snip --
When I look at the definition of struct dirent in
/usr/include/sys/dirent.h, I see this:
-- snip --
struct dirent {
#if defined(_KERNEL) || !defined(__BSD_VISIBLE)
ino_t d_ino; /* file number of entry */
#else
ino_t d_fileno;/* file number of entry */
#endif
uint16_td_namlen; /* strlen(d_name) */
uint8_t d_type; /* file type, see blow */
uint8_t d_unused1; /* padding, reserved */
uint32_td_unused2; /* reserved */
chard_name[255 + 1];
/* name, NUL-terminated */
};
-- snip --
It looks like this def is missing d_reclen, whereas the getdents
manpage mentions it - or am I missing something here?
Thanks in Advance,
Karthik.
Re: USB Pen drive
Hi Folks, I was finally able to borrow the USB stick for a little more fooling around, and this rather long email contains the results. To cut a long story short, no, it isn't working yet. I'd like to fool around a little more and get it to work, though, and I'd appreciate any help I get. Before I go further, I'd like to say Thanks a Lot to everybody who took time to reply :) On my box, running DF 1.5.4-Preview, the USB stick is still not recognized. What's more, kldloading ehci.ko results in my USB keyboard freezing :) This is what dmesg has to say about my USB controller: -- snip -- uhci0: Intel 82801FB (ICH6) USB controller USB-A port 0xff80-0xff9f irq 9 at device 29.0 on pci0 usb0: Intel 82801FB (ICH6) USB controller USB-A on uhci0 usb0: USB revision 1.0 -- snip -- On a box running DF 1.5.4-DEVELOPMENT, the USB stick is recognized. However, I wasn't able to see any filesystem on the stick. (I tried the same stick under NetBSD on the same machine, it worked just fine). This is what I got: --- snip --- uname: -- DragonFly mukan.vxindia.veritas.com 1.5.4-DEVELOPMENT DragonFly 1.5.4-DEVELOPMENT #2: Mon Jul 3 14:19:42 IST 2006 [EMAIL PROTECTED]:/usr/obj/home/links/src/sys/MUKAN_154_DEV i386 dmesg extract: umass0: vendor 0x13fe GEIL USB DISK, rev 2.00/1.00, addr 2 n pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered da0 at umass-sim0 bus 0 target 0 lun 0 da0: GEIL USB DISK 2.0 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) WARNING: da0 si_iosize_max=0, using DFLTPHYS. WARNING: da0 si_iosize_max=0, using DFLTPHYS. disklabel: -- # /dev/da0: type: SCSI disk: label: GEIL USB DISK flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 16 sectors/cylinder: 512 cylinders: 7872 sectors/unit: 4030464 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 16 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 40304640unused0 0 # (Cyl.0 - 7871) --- snip --- As we can see, disklabel doesn't recognize anything on the stick. Under NetBSD, however, this is what disklabel has to say: -- snip -- # /dev/sd0d: type: SCSI disk: mydisk label: fictitious flags: removable bytes/sector: 512 sectors/track: 32 tracks/cylinder: 16 sectors/cylinder: 512 cylinders: 7872 total sectors: 4030464 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 5 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] d: 4030464 0 unused 0 0# (Cyl. 0 - 7871) e: 403043232 MSDOS # (Cyl. 0*- 7871) -- snip -- Now, I'd like to fool around some more and get this thing working, but I have no idea what to do next. Any pointers from anybody, please? Thanks, Karthik.
Re: USB Pen drive
It'll take me a little while before I can fool around with that USB pen drive again, I'll get back to the list when I do. Thanks for all the replies, guys! K.
USB Pen drive
Hi Folks, Yet another newbie question - how do I use my USB pen drive under DragonFly? I just tried shoving it into the USB port, and watched dmesg - nothing happened! I have usb, umass, scbus and da compiled into the kernel. Is there a howto or something that talks about how to use a USB pen drive? Thanks in Advance, Karthik.
ethereal
Hi Folks, Has anybody managed to get ethereal up and running on DragonFly, via pkgsrc or otherwise? If anybody has, please please let me know what you did! Thanks, Karthik. -- There are things known and things unknown, in between lie the Doors
Re: Newbie scsi question
Hi Hans, udev is not a fix to this, it is the cause. You actually can use udev to get stable device nodes. Most distros don't care, though. The linux kernel provides a stable addressing in sysfs. udev should be configured to use this and not just enumerate serially. So the problem isn't there in the first place. Device node creation is already a userland task in linux and I can't see nothing wrong with that. Possible bad choice of words on my part - what I meant to say was this - you *have* to configure udev under linux - perhaps write a udev rule that says if the device id is such-and-such, then make the device accessible by this name. You don't need to do that under Solaris, it's solved much more elegantly. At least, for self-identifying devices. This will probably be a design question for dfbsd as well for the devfs reimplementation: What gets done in the kernel and what's left for userland when it gets to device naming? I for one will be eagerly awaiting the answer to this question :) Cheers, K.
Newbie scsi question
Hi Folks, I faced a small problem with Linux recently, saw how Solaris solved the same problem, and was wondering what DragonFly did. Disclaimer: I haven't worked with *BSD too much; so this could potentially be a question best answered by an RTFM. If this is the case, please point me to the right place, I shall be happy to read up. Here's the problem: Consider a typical SAN setup - an FC switch with a couple of JBOD's and a couple of machines hooked up to the switch. On linux, the disks from the JBOD are recognised as /dev/sd[a-n]. The hitch is that the device naming is not consistent across reboots; the first time around, /dev/sdb could refer to the first disk on the JBOD. The second time around, you don't know what it points to, as the assignment of device names to disks depends on the order in which the disks are recognised at boot time. Of course, there are fixes to this problem - like devlabel/udev, but they are essentially fixes to a problem that should never have been there in the first place. On Solaris, this isn't a problem - the disk's SCSI ID is incorporated into the device name itself - so you have devices like /dev/dsk/c3t210C502D3790d0s2. This way, the disk name is the same, regardless of the order in which the disks are recognised at boot time. In this kind of a situation, what does DragonFly do to ensure that the disk names are consistent across reboots? The easiest way to find out would be to run DF and see - but all boxes at work that are connected to the SAN are either sparc or amd64 boxes, and DF doesn't work on either of these yet. Cheers, Karthik.
Re: Newbie scsi question
On 5/3/06, Chuck Tuffli [EMAIL PROTECTED] wrote: Unfortunately, DragonFly (and most of the other *BSDs I think) doesn't have a good answer for persistent binding. You can setup the kernel to wire down a particular bus/target/lun to a specific device, but I don't think this would work for SANs. More on the same topic! Here's an excerpt from the linux fstab(5) manpage: --- snip --- Instead of giving the device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by its UUID or volume label (cf. e2label(8) or xfs_admin(8)), writing LABEL=label or UUID=uuid, e.g., `LABEL=Boot' or `UUID=3e6be9de-8139-11d1-9106-a43f08d823a6'. This will make the system more robust: adding or removing a SCSI disk changes the disk device name but not the filesystem volume label. --- snip --- Wonder if something like this would make sense for DragonFly? Cheers, K.
Assembly in DragonFly
Hi Folks, After installing DragonFly on a spare box at work, I was trying out asimple Hello World in assembly, and found that one needed to do alittle more than as -o hello.o hello.s; ld -o hello hello.o to getit to work; here's what I did: 1. Wrote a Hello World in assembly: hello.s =.section .data helloworld: .ascii Hello, World\nlen : .long . - helloworld .section .text .globl _start syscall:int $0x80ret _start:pushl $lenpushl $helloworldpushl $1movl $4, %eax call syscalladd $12, %esp # clean up stack pushl $0movl $1, %eaxcall syscall== 2. Ran as -o hello.o hello.s; ld -o hello hello.o; ./hello, and sawthis on the console: ELF binary type 0 not known.Abort trap 3. Running file hello produced this output: hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),statically linked,not stripped 4. Scratched head a little. Inspired by the lead of [1], wrote a smallHello, World in C, ran objdump on the executable. Et Voila, it lookedlike I had found what was required: Contents of section .note.ABI-tag: 8048110 0a00 0400 0100 44726167 Drag 8048120 6f6e466c 7900 d6fb0100 onFly... 5. I then added the following to the original hello.s: =.section .note.ABI-tag, a.long 0xA.long 0x4.long 0x1.string DragonFly.long 0x1fbd6== And it works! This probably isn't of much use to anybody except for crazy guys likeme who like to code in assembly once in a while - but I thought I'dpost it here anyway. Cheers,Karthik. --References: 1. http://mail-index.netbsd.org/port-i386/2001/08/21/0018.html, and http://mail-index.netbsd.org/port-i386/2001/09/03/0004.html 2. http://www.netbsd.org/Documentation/kernel/elf-notes.html#note-creation
