()s missing in condvar.h
Hi, ()s are missing around the macro argument in cv_waitq_empty. The call if(!(cv_waitq_empty(&sc->foo_cv))) ... will otherwise fail to compile. harti Index: condvar.h === RCS file: /usr/ncvs/src/sys/sys/condvar.h,v retrieving revision 1.2 diff -r1.2 condvar.h 66c66 < #define cv_waitq_empty(cvp) (TAILQ_EMPTY(&cvp->cv_waitq)) --- > #define cv_waitq_empty(cvp) (TAILQ_EMPTY(&(cvp)->cv_waitq)) -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Q] msgs
On Tue, Jul 03, 2001 at 06:43:08PM +0200, Karsten W. Rohrbach wrote: > omit the space? > /k I have tried with an ending space, it will not work and produce de same error. Actually, I have barely uncommented what was already there. I was suspecting permissions faultive, but as far as my tests goes, it's not the problem. as I was testing procmail, I had to add a .forward meanwhile I set the correct option in sendmail to use it as a backend, I had to put "|exec /usr/local/bin/procmail || exit 75" sendmail would just use to="|exec /usr/local/bin/procmail || exit 75" and it works! so, I don't know what's the problem with msgs. any more clue? ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Raw disk access in userland
On Wed, Jul 04, 2001 at 23:42:50 -0700, Mike Smith wrote: > > On Wed, Jul 04, 2001 at 20:18:51 -0400, Kevin Hui wrote: > > > Then the question is whether the kernel is copying data between userspace > > > and kernelspace or whether it just DMAs the data straight in/out of the > > > user program's address space. In Linux raw-io, given that it is a block > > > device and you are doing page-aligned block I/Os on it, is smart and does > > > zero copies. While it may seem to be jumping through hoops, maybe it does > > > have a performance advantage? > > > > The kernel copies between userland and the kernel. > > Er, no. > > See sys/kern/kern_physio.c for the details. *hits head* I (of all people) should have remembered that. I wrote the zero copy stuff for the pass(4) driver (see cam_periph_mapmem() in sys/cam/cam_periph.c) using physio as a model. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Raw disk access in userland
> On Wed, Jul 04, 2001 at 20:18:51 -0400, Kevin Hui wrote: > > Then the question is whether the kernel is copying data between userspace > > and kernelspace or whether it just DMAs the data straight in/out of the > > user program's address space. In Linux raw-io, given that it is a block > > device and you are doing page-aligned block I/Os on it, is smart and does > > zero copies. While it may seem to be jumping through hoops, maybe it does > > have a performance advantage? > > The kernel copies between userland and the kernel. Er, no. See sys/kern/kern_physio.c for the details. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Raw disk access in userland
On Wed, Jul 04, 2001 at 20:18:51 -0400, Kevin Hui wrote: > Then the question is whether the kernel is copying data between userspace > and kernelspace or whether it just DMAs the data straight in/out of the > user program's address space. In Linux raw-io, given that it is a block > device and you are doing page-aligned block I/Os on it, is smart and does > zero copies. While it may seem to be jumping through hoops, maybe it does > have a performance advantage? The kernel copies between userland and the kernel. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Raw disk access in userland
Then the question is whether the kernel is copying data between userspace and kernelspace or whether it just DMAs the data straight in/out of the user program's address space. In Linux raw-io, given that it is a block device and you are doing page-aligned block I/Os on it, is smart and does zero copies. While it may seem to be jumping through hoops, maybe it does have a performance advantage? Regards, -Kevin. On Wed, 4 Jul 2001, Kenneth D. Merry wrote: > On Wed, Jul 04, 2001 at 17:58:58 -0400, Kevin Hui wrote: > > Hi all, > > > > I'm wondering if *BSD have any support for user programs to access raw > > disk devices, unbuffered. Such support is available under Linux: > > > > http://www.kernel.org/LDP/HOWTO/SCSI-2.4-HOWTO/rawdev.html > > http://www2.linuxjournal.com/cgi-bin/linux/man.cgi?mode=search&comm=raw§=1 > > > > Any information regarding this would be appreciated. > > There are no block (i.e. buffered) devices in FreeBSD, only character > devices. > > So you can access raw devices without having to go through all the hoops > described above. > > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FW: CVS FYI (fwd)
U website/main/dbfiles/email_ad_tools.db cvs update: cannot change mode of website/main/dbfiles/email_ad_tools.db: Stale NFS file handle anyone know how to get rid of these. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Raw disk access in userland
On Wed, Jul 04, 2001 at 17:58:58 -0400, Kevin Hui wrote: > Hi all, > > I'm wondering if *BSD have any support for user programs to access raw > disk devices, unbuffered. Such support is available under Linux: > > http://www.kernel.org/LDP/HOWTO/SCSI-2.4-HOWTO/rawdev.html > http://www2.linuxjournal.com/cgi-bin/linux/man.cgi?mode=search&comm=raw§=1 > > Any information regarding this would be appreciated. There are no block (i.e. buffered) devices in FreeBSD, only character devices. So you can access raw devices without having to go through all the hoops described above. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Raw disk access in userland
Hi all, I'm wondering if *BSD have any support for user programs to access raw disk devices, unbuffered. Such support is available under Linux: http://www.kernel.org/LDP/HOWTO/SCSI-2.4-HOWTO/rawdev.html http://www2.linuxjournal.com/cgi-bin/linux/man.cgi?mode=search&comm=raw§=1 Any information regarding this would be appreciated. Regards, -Kevin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ftpd....
Hello, > Neither one of them hold a candle to the load CDROM.COM can handle. > How about we import dg-ftpd instead? I'm sure we'd all like to be > able to support 1TB a day of data transferred... Although it may be true (the cdrom.com load), the 1 TB per day stuff isn't so mystic. After changing from Linux to FreeBSD, my machine outperforms itself. My daily record is above 750 GB with a single PIII-450 and with 1 GB RAM. The best of all, that now I can handle more than 1500 concurrent FTP clients and if the half of this number downloads the same file from the same SCSI disk, the system does not slow down, like with Linux. It easily saturates the Intel Etherexpress NIC (100 Mbps). My dream is a complete *BSD mirror on it, but until that I have to find many-many sponsors (in Hungary OpenSource seems to be very widespread, but very few firms sponsor sites, like this, ftp.fsn.hu)... ps: I am using the standard FTP daemon with inetd (I don't know how to set a max userlimit when running in daemon mode correctly). Thanks for all of you for this great OS! -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: helping Wietse help postfix on FreeBSD
Len Conrad wrote: > > I´m trying to gather tuning information for Wietse Venema who says: > > "I'm writing a document that describes how to crank up FreeBSD so > that it can run lots of processes, and so that it can handle lots > of connections. > > Right now, these guidelines vary from sysctl, loader.conf, to > recompiling a kernel. This is confusing." This posting will probably piss a lot of people off, even though it's only a fraction of what you should actually be looking at, and I'm intentionally ommitting many things that let me get the numbers I do, until I can push them even higher out of reach. Telle est guerre. 8-). -- MOSTS IMPORTANT POINT: You are going on "Mr. Toad's Wild Kernel Recompilation Ride"; get over it: sit back, and you might even enjoy it. You are going to find you are constrained by memory; it does not help that FreeBSD has vastly bloated many structures in support of kqueue and similar things, instead of instituting unions and reusing fields, and using muxes for things, instead of individual callbacks. I don't suggest you rewrite your allocator unless you know exactly what you are doing; you can still get high numbers, but nowhere in the ballpark of the numbers I've been able to get (e.g. 1 million). I do _NOT_ recommend that you try to beat my numbers, unless you have 16 years kernel experience and about a month to sift through and understand the code, and another couple of months to rewrite everything that doesn't scale. You can increase the KVA space, but the documentation in the handbook that talks about how to do this is actually woefully inadequate, since it misses several "magic" numbers, and fails to give derivation for the others; I would prefer that the code be fixed, so I'm not going to document the process here. Another thing you can do is crank up the maximum number of open files. For networking, this _MUST_ be done before the tcpcb's, struct sockets, and inpcb's have had space allocated, which means at boot time, if you want it to actually appy to network connections. If you tune this at run time, your connections will remain limited to the value at boot time. Because you can not tune this value in loader.conf without using the patch I posted for /sys/conf/param.c, and since no one has committed it (people complained about how it was done, but didn't provide their own code to do it any better), you are basically stuck with rebuilding your kernel with a high "MAXFILES" in your config. Your kernel will use this value to set somaxconn (and the allocation of sockets), which in turn will determine the number of inpcb's and tcpcb's, which will then limit the number of network connections you can have simultaneously. If you are using FreeBSD 4.3-RELEASE, you _MUST_ not set your maximum files above ~32000. This gives you some headroom from the maximum value of an unsigned short reference count in the ucred structure, since ucred's are inherited, and there is one reference per file descriptor, and one per socket (personally, I just don't get the reasoning behind the socket refrence, since the only way you can access the thing is through a file; the places where it's tested seem pretty stupid to me). I posted a patch for this, too, to -arch and -current; I think it was effectively brought in as an "MFC" to the -STABLE branch, but don't quote me: look in cred.h instead. You can hack your cred structure to use an unsigned long, instead, but you will have to rebuild *everything*, and say "hello ports" and "goodbye, packages". Don't expect to be able to make more than 64k of outbound connections, unless you are willing to rewrite the port allocation hashing code, since everything is allocated out of the same collision domain, unpreterbed by having multiple IP addresses. Inbound connections are not a problem, since they don't use up local ports. Software can work around this problem (I routinely load test from one of my desktop boxes at ~180,000 client connections from 3 virtual IP addresses), but to do so, you have to understand _exactly_ how the allocation works, and dance yourself through all the limiting "if" tests from user space -- not for the faint of heart (ever play one of those "milk bottle fishing" games at a county fair?). MBUFS and NMBCLUSTERS almost go without saying... You will use one mbuf per connection for keepalives, and may spend more, if you set non-default options. Mike posted a patch for this, which gets rid of the TCPTMPL structure. This patch helps scaling, but it turns out that it's an incredible performance lose, in testing. Much better to use something like my chain allocator, and recover 196MB of memory (at a million connections), and leave the tcptmpl there; it turns out that there are at least 4 "interesting" uses for the thing, aside from keepalive. Oh, yeah: his patch also kills TCP_COMPAT_42: also an incredibly bad thing. I will say: DO NOT USE A BIG "MAXUSERS"! This cranks up many things your server couldn't care less
Re: ftpd....
>Mike Smith wrote: >> Unless I'm mistaken, the current ftpd doesn't offer the >> functionality you're asking for either, so there's no >> valid reason to block the import of the lukem ftpd on >> these grounds. >> >> And, I'm quite certain that Luke would happily consider >> patches, if you were to put them forward. > >Neither one of them hold a candle to the load CDROM.COM >can handle. > >How about we import dg-ftpd instead? I'm sure we'd all >like to be able to support 1TB a day of data transferred... dg-ftpd isn't freeware. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ftpd....
On Wed, Jul 04, 2001 at 12:48:38PM -0700, Terry Lambert wrote: > Mike Smith wrote: > > Unless I'm mistaken, the current ftpd doesn't offer the > > functionality you're asking for either, so there's no > > valid reason to block the import of the lukem ftpd on > > these grounds. > > > > And, I'm quite certain that Luke would happily consider > > patches, if you were to put them forward. > > Neither one of them hold a candle to the load CDROM.COM > can handle. > > How about we import dg-ftpd instead? I'm sure we'd all > like to be able to support 1TB a day of data transferred... According to jkh it's quite ftp.FreeBSD.org specific ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ftpd....
Mike Smith wrote: > Unless I'm mistaken, the current ftpd doesn't offer the > functionality you're asking for either, so there's no > valid reason to block the import of the lukem ftpd on > these grounds. > > And, I'm quite certain that Luke would happily consider > patches, if you were to put them forward. Neither one of them hold a candle to the load CDROM.COM can handle. How about we import dg-ftpd instead? I'm sure we'd all like to be able to support 1TB a day of data transferred... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Config devices not in machine
Mike Smith wrote: > Is there ANY penalty for having a device in your config file > that is not in your system?? Yes. It can take I/O bus resources, IRQs, and memory that might otherwise be put to better use. > I am inheriting a 40 machine laboratory. My predecessor > decided to go to a single config/kernel for all machines > I'm sure for administrative convenience. I'm trying to > determine if there is any major penalty for using this > single "source" for all machines. It depends. Some legacy ISA devices are not capable of being identified and having their drivers automatically loaded; if these machines are "fully PCI", with the only legacy ISA devices on the motherboard, it should be fairly easy to move to using modules for everything but those integrated devices. In FreeBSD, you will find that almost everything but the devices in the boot path are capable of being demand-loaded only in the case that the hardware is actually present. This means that if your config covers your disk controllers on all your machines (this may mean several drivers have to be ther), pretty much everything else can be left out, so long as it isn't in the boot path (yes, the console is in the boot path; so is the keyboard, etc.). So you could cover all your ISA devices and boot devices, and let the PCI probes identify the other drivers that need to be loaded. > Since we are doing significant hacks on FreeBSD to support > proprietary FAA protocols and equipment obsolete to the rest > of the world, I want to have as clean a kernel as possible > to start from. Cool project. I suggest you build a netboot floppy, and then set up the test image load, with all modules, on one machine, and then netboot all of the PC's from an NFS export of that image (one at a time, of course). This will let you verify that you have the minimal necessary drivers to get your network and the disks recognized, and from there you should be able to decide on the proper "cut down" image. If you were really lazy, and knew perl (aren't those actually synonyms? ;-)), you could just netboot the full image, and save the dmesg off onto the server (e.g. dmesg.), and then process them all to get your minimal spanning set, and do a "hardware survey" of the equipment. If you then included only the list of hardware in the boot path, you would have your "minimal kernel config", based on the probe messages at boot time. Actually, this would probably be damn useful to a lot of people... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Status of dialog(1) and libdialog.
I suppose that depends on how you define "future." Do we want to be using libdialog in the year 2010? No, I would certainly hope something better will have arrived by then. Do we have anything better now or in the forseeable next 12 months? No also. So, if there's anything you or anyone else can do to improve the state of libdialog, I'm sure it will be of some use. Oh yeah, and I might as well take this opportunity to state this for the public record: I DID NOT WRITE THAT EVIL THING. :-) It was written by some guy in Hong Kong and extended by the slackware folks. I just added the callback mechanism stuff so that the objects weren't just "blobs" with no access to internal state transitions. So blah! :-) - Jordan From: "Andrey Simonenko" <[EMAIL PROTECTED]> Subject: Status of dialog(1) and libdialog. Date: Wed, 4 Jul 2001 13:07:12 +0400 > Hi All, > > I'm working on some patches for dialog(1) and libdialog. > Does FreeBSD team want to continue use of dialog(1) program > and libdialog in future? I ask this question because I fix > some problems I have with dialog(1) (really with libdialog) and > I'm going to try to fix the same problems with all functions in > libdialog, so I want to know if it will be interesting for FreeBSD. > I saw some bug reports for dialog/libdialog, but didn't see "good" > reactions on that PRs. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pthreads vs set/longjmp performance (homegrown tasking)
Hi, I have an application which uses a homegrown tasking mechanism. Basically, it uses setjmp/longjmp where the stackpointer is modified after the setjmp and before the longjmp. This allows multiple 'tasks' to run (serially) within the process with each having a different stack allocation. The above process is then run on top of a single pthreads thread. With the newer pthreads libraries, this code nolonger works: Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line ? in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = ?) Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line ? in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = ?) Instead of possibly modifying the pthreads library, I decided to convert the homegrown tasking to simply always use pthreads. I have this working, unfortunately, the performance of this implementation is much slower: setjmp/longjmp: initialization time: real time0.12 seconds cpu time 0.08 seconds pthreads: initialization time: real time0.82 seconds cpu time 0.79 seconds About a 7x performance loss. I am using 'pthread_cond_signal()' to activate each successive thread thus avoiding the overhead of a 'pthread_cond_broadcast()'. Pthread_setschedparam() doesn't seem to have any effect. Two questions: Has anyone dealt with type of problem before? If so, what approach did you take? Has anyone thought of adding/implementing a (not posix standard) way of informing pthreads to allow multiple stacks to be swapped in and out on a single pthreads thread (thus allowing the previously accepted semantics to continue working?) Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: recent 4.3-stable freezes my SMP box
At 6:56 PM +0100 7/4/01, Koster, K.J. wrote: >Dear All, > >I just upgraded one of my boxes to FreeBSD 4.3-stable with cvsup. >Unfortunately the machine now freezes. If you are tracking -stable, then there is a lot of good reason to keep an eye the freebsd-stable mailing list. Particularly when something like this comes up. If you check that mailing list over the past week or so, several different people have experienced similar problems, and have been discussing it. The most promising info is in recent messages from [EMAIL PROTECTED] in the thread "Hard lockups since cvsup'ing Jul 1st. Help!". It looks like he's got patches to fix the problem most people have been running into. I don't think they have been committed yet, but the patches are there (in the messages) if you want to try them. Given how unreliable your system is, you'd probably have to boot using "kernel.old" or boot into single-user mode to compile things with these patches applied. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
recent 4.3-stable freezes my SMP box
Dear All,
I just upgraded one of my boxes to FreeBSD 4.3-stable with cvsup.
Unfortunately the machine now freezes. I can ping it and it responds to
[ctrl][alt][esc] on the console ("No debugger in kernel") and I can switch
consoles [alt][F1..4], but it does not respond to other keyboard events. For
example [ctrl][alt][del] does not work.
The machine is a Compaq Proliant, dual 550MHz Xeon, with a hardware raid
SCSI box that comes up as sym0 (875).
I powercycled the box, since I cannot actually log in to see what's up. The
system boots, gives me a login prompt and subsequently freezes again.
Booting into single user more allows me to fsck and mount and look around
for a bit until is also freezes. A verbose boot gives me one message that I
worry about a bit (from memory:)
APIC_IO: MP table broken 8259->APIC entry missing
Should I worry? What SMP related stuff went into -stable in the last month
or so? Anything that might freeze my box?
I have two very similar Proliant uniprocessor boxes that appear to work
fine, but the SMP box is their NFS home dir server. This prevents me from
logging in remotely at this moment to check. It's after hours here.
The machine has been stable for a few months, and I upgrade -stable every
first week of the month. This box is the buildbox that I built all -stables
on so far, so I'm quite sure this box is a-ok.
More tomorrow, when I get access to the actual server console again. Any
hints appreciated. In particular: how do I get back to last week's -stable?
:-)
Kees Jan
You are only young once,
but you can stay immature all your life.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
No Subject
does bsd supports S3 SAVAGE Video card? and any redfox motherboard? help me pls? and does it supports LG COLLINS Cd-ROM? tnx! pls reply asap pls? tnx!!! pls help me, or what other hardware does bsd support? tnx ive got only a limited net connection pls reply via email... tnx! -bsd user- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TX buffer in 4.3
Randy -Harborside Internet([EMAIL PROTECTED])@2001.07.03 13:53:43 +: > > We are having a problem with our mail server. It recently got > upgraded to 4.3 from 4.2, and now it is having problems with the TX > buffer somehow on the network card. Every once in awhile it will shut > off all network traffic and give these errors: > no memory for tx listrl0 > Then in a few minutes (presumably when the buffer is flushed somehow) > the network device resumes normal operation. > We have tried 3 different NICs, and all have had the same problem. > The three models were: > 1. Realtek RTL8139A 10/100TX > 2. Intel chipset:82558B > 3. 3Com somethingerather. > > We are running with 512MB of RAM, and it usually has about 200 or > more megs free at the time of this occurance. in this case i think putting options NMBCLUSTERS=32768 in your kernel config would solve this problem also bumping up MAXUSERS helps... /k -- > Absinthe makes the tart grow fonder. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x PGP signature
Re: C++ to C translator
> Hi, > > I have written some code in C++. However, I want to run it on an old > mainframe machine, which a C++ compiler is not available. > > I know that the old g++ is a C++ to C compiler. Does anyone know which > version it is? Also, anyone knows other C++ to C compilers? > > Thanks, > Rayson Rayson, There are several C and C++ compilers available for the mainframe. (if you mean zSeries (nee IBM 390) mainframe. We market a C compiler & HLASM compatible assembler (available natively, or as a cross-compiler/assembler.) See http://www.dignus.com IBM markets C & C++ compilers. And SAS Institute markets C & C++ compilers, see http://www.sas.com. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Status of dialog(1) and libdialog.
Hi All, I'm working on some patches for dialog(1) and libdialog. Does FreeBSD team want to continue use of dialog(1) program and libdialog in future? I ask this question because I fix some problems I have with dialog(1) (really with libdialog) and I'm going to try to fix the same problems with all functions in libdialog, so I want to know if it will be interesting for FreeBSD. I saw some bug reports for dialog/libdialog, but didn't see "good" reactions on that PRs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
