Re: Hardware support for AMD Geode CS5536 audio?
Hi, re Carlos A. M. dos Santos comment: The amd5536.c informs that it is derived from Bruce R. Montegue's AMD CS5530 audio driver and the Linux CS5535 ALSA driver. I did not find the original source files, but supposing that they are licensed under GPL you will need a written permission from the owners to redistribute the code under a different licensing terms. For orignal source: http://63.249.85.132/gx_audio/Makefile http://63.249.85.132/gx_audio/ns_geode.h http://63.249.85.132/gx_audio/ns_geode.c Doc: http://63.249.85.132/gx_audio/index.html I wrote the CS5530 audio driver referenced around 2001, it was always a FreeBSD driver under a modern BSD-license. The driver was never GPL-licensed. The audio driver was developed on FreeBSD during a contract for NatSemi (who owned the Geode at the time, they had just brought Cyrix). The driver was part of an effort to undo drivers that had been put into the Geode's hypervisor (sort of an extended ACPI that provided device emulators (device models); it turned out that was considered reverse engineering hardware and so was a no-no). The driver was done from scratch, from the manuals, with occasional help from Cyrix engineers. As I recall, FreeBSD helped a little with the final debugging of the Geode hardware, booting a picobsd floppy became part of the standard test suite. At the time, I found it convenient to email floppy-sized picobsd systems that demonstrated a hardware bug to remote hardware engineers. -bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
Hi, re Continuous Data Protection (an enterprise market niche, today), a recent paper that provides some background and has basic references might be: http://www.usenix.org/event/fast08/tech/verma.html SWEEPER: An Efficient Disaster Recovery Point Identification Mechanism, FAST '08, Akshat Verma, IBM India Research; Kaladhar Voruganti, Network Appliance; Ramani Routray, IBM Almaden Research; Rohit Jain, Yahoo India. -bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch for working AMD Geode CS5530 audio driver on HEAD
Hi, Rink. re: The patch is available at http://people.freebsd.org/~rink/various/ns_geode.diff Sounds great! (ok awful pun.) I am interested in integrating this work in HEAD ... My FreeBSD development environment has been down for a few years and, despite optimistic hopes, due to day job and real life, cough, I won't be able to do anything with this driver till mid-September (if then). So as far as I am concerned, anyone who wanted to take this driver and run with it, well, that would be great. (in particular as I seem to be suffering from infinitly receeding deadline syndrome.) I know Andrew Grey (ancelgray at yahoo.com) was starting to hack on the CS5536 stuff... -bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Re: Hardware support for AMD Geode CS5536 audio?
Hi, re: Bruce, This is Andrew Gray. I am running an Alix-1C board with the CS5536 on it. This board is very nice. It's only about $138 and it has a good standard clone AWARD bios that we are all used to (unlike say, the Soekris boards). It uses only 5 watts and has everthing including 21 GPIO pins. (except is doesn't have a Freebsd sound driver yet. ---snip--- http://www.mini-box.com/Alix-1C-Board-1-LAN-1-MINI-PCI?sc=8category=754 Looks like a nice board, close to the reference platform, and has exposed audio (unlike some of the Geode-based embedded systems). Looks like a decent CS5536 audio development platform. Its use of the CS5536 is not apparent from a casual skim of the web-page, thanks, I would not have known about it if not for your mail. A question for you? Do Freebsd 4.6 drivers still work on freebsd 6.2 and 7.0? Not sure, I haven't had relevant Geode hardware up for awhile... I'd be rather surprised if even for the CS5530 something hadn't changed or needed tweaking, but I don't know. Are you working on this CS5536 driver? Do you have hardware yet? I don't have hardware, but I've just ordered an Alix-1C. :) I haven't been working on this. I had googled for a few days without finding anything that looked like a convenient dev platform (mostly closed embedded systems). I also came across info at AMD's site that implied the CS5536 had been end-of-lifed and that made me a bit depressed. Does anyone know, BTW, if this is the case? When I get this Alix-1C I will try to get something up. But it will definitely just be in all-too-infrequent spare-time cycles between real-life and dayjob, so we're talking weekend-and-late-night-hobby here. If anyone such as yourself want to hack away on it, that would be great too. I'll try to stay in touch. Thanks, -bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardware support for AMD Geode CS5536 audio?
Hi, re: I'm hoping someone will be able to help me out with the audio is the Geode CS5536. Those AMD Geode systems with the CS5536 look almost cheap enough to afford one for each hand. I'll look into upgrading the 5530 audio driver for the 5536, but it will take sometime. If someone does it over the weekend, or somesuch, let me know... (likewise if anyone has other advice on good current Geode kernel development platforms). -bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardware support for AMD Geode CS5536 audio?
Hi, re this from Alec Kloss, 21 Jan 2008: I'm hoping someone will be able to help me out with the audio is the Geode CS5536. This has come up a few times before, once early this month and once last February. The CS5530 driver mentioned on the soundsystem wiki doesn't work. ... Original FreeBSD gx5530 driver: ... Hi, I wrote the geode audio driver for the CS5530 (found at the mentioned link), a good while back, I think for FreeBSD 4.x. This week is the first time I've received any feedback on this driver, a couple of pings along the line of the above. I honestly hadn't realized anybody was using it (I guess that's the problem with it working). If there was a thread last february, I must have missed it. I dont think I've ever seen the soundsystem wiki. I would try to fix/upgrade this driver if I had any hardware with a CS5536, but I don't. That said, can anyone recomend a cheap system that includes the CS5536, is generally available, doesn't cost very much and can be used as a minimal dev platform? (Surely all the OLPC work has made some interesting such systems available?) Or would anyone want to donate a free current AMD Geode reference platform? :) Even with hardware, it would probably be at least a month before I had time to look at it. Someone who knew FreeBSD drivers could probably fix it in a few compiles, if 5536 device-specific initialization is the problem. I only vaguely recall some of the initialization issues---I think there is a magic bitmask that has to be passed to the hypervisor (perhaps indirectly) to tell the hypervisor what _not_ to manage, so the FreeBSD driver will be able to manage it. I really hope this interface requirement is documented better for the CS5536 than the 5530, but maybe things weren't as bad as I remember. I think there can be a lot of dependencies between the CPU step, BIOS version, hypervisor version and southbridge (5536) version. It's kind of interesting to note that the Geode had a hypervisor in the firmware about a decade ago, somewhat similar to the manner that folks like VMware are now starting to do with ESX 3i hardware-integrated hypervisor, etc... (the Geode hypervisor did not provide multiple CPU instances, rather virtual devices). -bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Van Jacobson's network stack restructure
Hi, Frank. re: http://lists.freebsd.org/pipermail/freebsd-hackers/2006-February/015365.html Who's calling? :-) Frank The original email to which you link above occurred in a discussion regarding the performance, architecture, evolution (or somesuch) of the FreeBSD network stack. The FreeBSD network stack is arguably about the most direct descendent of the TCP/IP stack that was done (forked from a BBN stack, I guess) at UC Berkeley. One reason the UCB (and FreeBSD) stack is of interest is because it essentially became the reference implementation for the modern TCP/IPv4 implementation. In university networking classes, noting that the first TCP link outside of a single lab was between Stanford and London (and thus that the Internet has always been International) makes a good story. Unfortunately it is hard to answer the invariable follow-up questions. I found very little info available the last time I looked (a few years ago). But maybe I missed the obvious. Did you do the UCL PDP-9 implementation on the first link? Was it a stand-alone program? What did it do? Kind of a ping? A test or performance program to debug things? What was the network device like? Did this program evolve, or was the PDP-9 just too small? Was your TCP written in Babbage? Was Babbage an assembler or a structured assembly language with control flow and expressions? Is there any published doc on this language (or programming environment)? How did you work with the Stanford folks? Was the work with the protocol done to a wire spec, or did you look at their implementation? Did you work with their BCPL version of TCP, or hand-port BCPL to Babbage assembly code? etc. etc... Was anything written up and published? Where? (I did try to contact UCL, to no avail.) Alas, all to often today if it's not electronically indexed it's as if it didn't exist. Was this info classified at the time? (I saw somewhere that the big push for a portable standard digital network link to Britain was that Norway happened to have an existing seismic-monitoring network close to a particularly interesting Arctic test site... is this true?) Sorry to go on at length with so many questions. There was some nice information about a new study of the Antikythera mechanism today, surely the mysterious PDP-9 and it's Babbage programming environment can yield a few clues! :) Please correct me anyone if I've got something wrong. - bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone have a picoBSD image?
Hi, re: I need a picobsd floppy image, (anything that can get me to a shell that will allow me to dd if=/dev/zero of=/dev/ad0 bs=1M ) On old 485 motherboards... if nobody else has contacted you, I put an image that should do this at http://63.249.85.132/ It is under the page PicoBSD Related Resources. I put a 4.3 and 4.9 image there. If they dont work, somewhere I have a bunch of other images for many circa-2000 PCs... - bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Van Jacobson's network stack restructure
Hi, hope this isn't too off-topic, but it's a reasonably hackery follow-up re a minor historical question instigated by Van Jacobson's Slide 6, which contains the following point: First TCP/IP stack done on Multics (1980) Presumably this means the first version of the specific TCP/IP stack with the architecture that evolved/forked/more-or-less-directly-was-reimplmented to become the BSD kernel-resident TCP/IP stack. 1. Was this first Multics stack written in PL/1? Based on literature/web, etc., the very first implementaton of TCP was a 24 Kbyte BCPL program written by Richard Karp at Stanford for the ELF operating system (this was in Cerf's lab). In 1975 the first test of TCP outside a single lab occured when a link was established between this stack and a TCP program of some sort written in Babbage by Frank Deignan on a very small PDP-9 at University College London. BBN did a 3rd independent BCPL implementation of TCP under (user-level) TENEX. All 3 TCP stacks first inter-operated in 1977. TCP was split into TCP and IP in 1979. The sliding window protocol comes from Pouzin's Cyclades system (which became operational in France sometime between 1972-1974; Cerf and Kahn acknowledged the influence of Cyclades on TCP); Pouzin had worked at MIT on CTSS and coined the term shell. 2. Was the Multics stack based on one of the BCPL stacks? 3. Does anyone know anything about the UCL Babbage TCP implmentation, or anything about the Babbage language? (I assume it was a structured assembly language, similar to PL/360 or SUPMAC). 4. Does anyone know anything about Frank Deignan? Just curious, have tried to find out information about this for awhile. Thanks in advance if you know anything relating to any of this. - bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvi for serious hacking
Hi, (wondering off on a tangent), re: I was using screen oriented editors over a 1200 baud dialup line in 1977 on a PDP-11 running RSTS/E on a Behive... Around this time I think full-screen editors from DEC that took advantage of the VT-52 (and later VT-100) included KED, EDT, and maybe SOS? EDT and KED took good advantage of the alternate keypad, basically the same keypad as on PC keyboards today. Weren't there full-screen editors on PDP-8's before this? Doug Engelbart's NLS demo in 1968 may not qualify as available, but he demoed full-screen editing with a mouse: http://arstechnica.com/articles/paedia/gui.ars/2 The demo featured hypertext linking, full-screen document editing, context-sensitive help, networked document collaboration, e-mail, instant messenging, even video conferencing! NLS ran on a version of UC Berkeley's Genie system, which can be considered an ancestor of Unix (maybe more-so than Multics?) Although early versions of TECO may not have supported direct-cursor addressing, TECO might have played a role in popularizing the notion of full-screen editors. From the wikipedia: TECO became well-known following a DEC PDP-6 implementation developed at MIT's Project MAC in 1964. This implementation continuously displayed the edited text visually on a CRT screen, and was used as an interactive online editor. This was, however, neither its origin nor its originally intended mode of use. Later versions of TECO were capable of driving full-screen mode on various DEC RS232 video terminals. - bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Driver Development Books?
Hi, re: The problem that I am having right now is that I have a fairly nice graphics card which, for the moment is only supported on Windows Operating systems, and old 2.4 Linux kernels. Someone mentioned X drivers; current X drivers are dynamically loaded into the X server, which runs in user-space, not in the FreeBSD kernel. The X server has its own ELF loader to load modules and drivers. This approach allows X drivers to be independent of OS. There is some documentation on writing X drivers at: http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/doc/DESIGN (Click on the (download) link at the top of the page) For a walk through writing a driver, see Section 20 at the end, Some notes about writing a driver. Alternatively, access http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/doc/ and select DESIGN, etc.. FreeBSD currently uses x.org (cvs.freedesktop.org), but the DESIGN doc is probably similar. The design doc has a lot of good background and conceptual material, enough to enable reading of real X drivers, which are the real definition of how things work. Although the mechanics of writting (or modifying) an X driver are very easy (almost trivial), if you have never worked with C or drivers before, expect a steep learing curve... probably starting by rebuilding X from source would be a good first step. - bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Google SoC idea
Scott Long wrote: Again, I'm not exactly sure how a generic mechanism can handle the distinction of data vs. metadata vs. journal data. Also, what you Ivan Voras wrote: I don't care about the distinction at this level - all data is treated equal. Scott Long wrote: But for journalling to work, you must care about the distinction. Ivan, some recent PhD dissertations probably discuss some of the dragons lurking in this area. For instance, see the thesis research discussion and papers in: http://www.cs.wisc.edu/~muthian/ His paper Life or Death at Block-Level might be of interest... - bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sudden Reboots
Hi, Andrea, regarding inverted page tables: Actually, all Power and PowerPC chips have this... Thanks for pointing that out. I believe the entire line of IBM virtual memory hardware that supports IBM's form of inverted page tables is all directly related, if not the same, and descends from the never-completed 1970s-era IBM Future System (FS) project. Or perhaps it was a version redone for the System/38 that used lessons learned from the FS? Is this right? The AS/400 has successfully used this architecture for a long time. Most of the other systems that have used this architecture (RT, RS) seem to have never quite caught on. Is this VM unit and the Power/PowerPC's the same? They cheat a bit with a hash table to keep the cost of the associative memory down; perhaps increasing its size is the natural evolution of this VM architecture? Are there any true single-level store OSes running on this inverted PT hardware? (That is, where RAM is literally treated as just an invisible performance cache for a secondary-storage primary memory.) I assume the OS/400 is, but maybe an expert knows for sure? OS/400 runs on modern AS/400's which use the PowerPC, unless I'm mistaken... Sorry to have so many questions and no answers, hopefully the coffee will kick in soon. The FS apparently was IBM's biggest failure; some say it had a lot to do with the growth of silicon valley. A history of the IBM Future System and the technologies it spawned would be very interesting. There seems to be little info on it around: www.cs.clemson.edu/~mark/fs.html - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sudden Reboots
Hi, re: The odd thing was that it was happening at virtualy the same time every morning [...] Then, they both just *stopped doing it by themselves* with no apparent correlation to anything installed software-wise. Neither server has had any problem for over a year now. * What was the external power situation, grounding, static situation, or other noise? Was the UPS or power-conditioning OK? Any large radars nearby? :) Radars have actually been known to matter. I once knew a system that died like this and it turned out to be because it was mounted three floors above a loading dock... a ROM pin or somesuch was doing a great job as a vibration detector, whenever trucks backed into the dock hard. Which brings up the question, what's the cheapest/best way these days to atually monitor high-res sags/spikes/sags on the line into a box? Decades ago it was a Drantez meter; I see they're still around: www.dranetz-bmi.com Does anyone have any such line-monitor unit that they particularly recommend as a good low-end buy? * Handwaving general remark about VM space overhead... Early virtual memory systems rapidly ran into the problem that all of physical memory became consummed by page tables. The solution was to page the page tables (which is why modern architectures support hierarchies of page tables). As systems become larger this solution typically becomes less-and-less effective, because each page in every _virtual_ address space requires a page table entry. If you have many large addresses spaces, this requires many page table entries total (this acts as pressure to make pages larger). The page tables become large data structures; managing them (keeping parts in memory when needed) can become a bottleneck. If you have other restrictions (the page tables have to fit in an address space segment, say, a kernel data segment), the virtual space allocated for this data structure can become exhausted. A kernel usually needs to have page tables that can map every page of physical memory, so for this page table, the more physical memory present, the larger the table. Page tables are used because they allow a page table entry to be accessed via a simple addition based on most of the virtual address. This is fast. As address spaces grow above 32-bits, the potential size of the page tables becomes more important. For very large address spaces some form of single-level store or inverted page table scheme is often proposed. Instead of having a page table entry for each page of virtual address space, these systems have the equivalent of a page table entry for each page of _physical_ memory. All addresses are effectively disk-block+offset addresses; the virtual memory hardware does an associative search to locate the physical block in memory that corresponds to the disk-block. This requires more expensive hardware then a simple addition, but such systems only require a page table entry for every page of physical memory. These systems have been built from early days, but are typically not competitive with VM systems that require simple addition. (I think the IBM AS/400 is the only widely-used commercial hardware using this approach) At some point address space growth, cheap associative lookup memories, and required page table size may make this approach competitive. - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Geode based PC/104 micro board and FreeBSD
Hi, very likely you have hit a known issue on the original Geode. In generic_bcopy in i386/support.s FreeBSD occasionally does a byte-aliged long rep move in the video buffer that locks the geode hard. See the patches at the following (it is a trivial patch): 63.249.85.132 63.249.85.132/geode.html 63.249.85.132/geode.html#patch_bcopy If you have no other means to fix this, there is an old 4.7 patched CD image at the above site that will boot on the Geode. I'm guilty of not submitting this as some sort of patch; it seemed a few years went by and there was no need/interest. The Soekris apparently never exercises this video code. I'll look at this again if I have time. The Geode II (and maybe other geode variants) supposedly don't have this problem, but I don't know... - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Next Generation kernel configuration?
Hi, re rule-based configuration Chris Pressey noted: That's the easy part. The hard part is discovering the dependencies. My impression is that almost all rule-based expert systems of sufficient complexity that deal with a dynamic field have failed because of this, that is, due to the difficulty of determining current dependencies (rule discovery). Even the experts don't actually know; each will know some but nobody will know all, certainly not when the real dependencies are evolving all the time. Even worse, there may be many combinations of things that just don't work but nobody realizes it yet, new things that break a lot of old dependencies in an unknown way, etc. Even the experts will hit this and ask on an email list, I did this and look what happened, anybody got any ideas? So the experts will know how to solve the problem, but not in a way that can be automated. Unix has been pretty good over its life at resisting combinatorial complexity; RSX for instance had a relatively high degree of optional API sets and optional API features and similar things with kernel primitives, this introduced a very fine level of granularity that made for a bad dependency combinatorial explosion (part of this resulted from the old OS/360 mantra of one system that would scale across a very wide family, combined with paranoia about memory use). Feature sets selected for server components depended on other feature sets, kernel feature sets, API feature sets, driver features sets, etc and vice versa. My impression -dont know if it's true- is that the RSX experience made DEC say never again. One important reason was testing. Testing a system when few others would actually be built exactly like it raises issues... its good to know that it at least works... but how fragile is it wrt other build combinations? The large e-mail list as build expert-system of choice combined with a simple mechanism (flat files) to act as control knobs is likely a big advantage open source systems have over most proprietary systems. It would be interesting to know how many people world-wide are reasonably competent to build FreeBSD from source compared to how many actually know the same for NT. Maybe all the more reason to package something as an Assistant type educational, verification, or visualization tool for stable, well-known core dependencies. FreeBSD will be around for a long time and such a tool, if nothing else, might help get people on board w/o any impact wrt the current state of affairs. If nothing else, it's an interesting problem and systems complexity is not likely to go down anytime soon! - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Next Generation kernel configuration?
Hi, re, Next Generation kernel configuration: Years ago I had a job for a few years where I constantly built RSX-11 systems on PDP-11s. RSX-11 was always built from source and had a couple of hundred build-time options, many hardware build dependencies, and supported numerous other dynamic build-time functions; it was said that it was possible that no 2 RSX systems were really the same binaries. It may have been more combinatorially complex than FreeBSD. An RSX build could easily take a day. Although at the core the build was driven by a file of assembly macro defines, conceptually not unlike FreeBSD, the build process went through continuous evolution over the life of RSX. A comprehensive sysgen.bat script, or somesuch, evolved. Sysgen (which was a common industry term at the time) was a very large script that was intended to be run on a fast hard-copy decwriter; it printed out lists of possibilities and then asked you a question, you made a selection from the options, and so on. It conducted a 'scripted dialog' that reflected the options you made along the way. You wanted this on hard copy so you could go back and check things, keep it for next time, and so on. You could go back in the dialog and repeat a section, save the sysgen state and restart later, and so on. A sysgen dialog could easily take half-a-day (sometimes intermediate things had to be built and such), and then the build itself and install could take a number of hours... At the end of the sysgen dialog you could save the session, basically, and then the next time you did a session you could ask to use the saved session and essentially conduct a modification dialog. Working with sysgen often felt like taking part in an adventure game with an AI opponent; you had to know how to outsmart the script to get it to do exactly what you wanted. This might be a common failing of many pseudo AI type programs. On the one had this all worked and worked well. On the other hand if you can do it by simply editing flat files it's much better, because you don't have to become an expert on the sysgen script just to do a build. Back on the other hand, there may be a point of complexity (and lack of corresponding widespread sophistication) where a sysgen program is necessary. SO: If a sysgen-like program was built for FreeBSD that used a conversational, graphic, menu, or whatever interface, instead of actually doing anything to real files or the real system, could it just print out _what to do_, that is, it would output a list of instructions - in such-and-such a file, edit this option, then add this line... Or perhaps it would output diffs to files... or put the output in a candidate location. But in any case the program would be a SYSGEN ASSISTANT, not an actual sysgen program. Basically a kernel config checker, a smart build-lint, etc.. It could live in ports. If this program got to where it really worked, everyone liked the interface, and the system complexity was clearly at the point where it was needed, it could be used to directly generate system configurations. The dependency-rule evaluation and output part could be built independent of any user-interface, so a front-end back-end scheme might make sense. In any case, googling on RSX sysgen might produce some ideas of interest. BTW, I'm under the impression that for quite some time the largest rule-based AI application (real-time expert system) in the world was the OPS5 system implemented at DEC to configure VAX hardware, see links such as: http://encyclopedia.thefreedictionary.com/OPS5%20rule%20based It looks like there's a public domain system that compiles rules to C code, perhaps there are some interesting ideas there as well for things like general dependency rule evaluation in the backend and such: http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/expert/systems/ops5/0.html Sorry to go on at length. - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc strangeness
Hi, re: one of my friends has raisen very strange issue regarding gcc rounding: printf(%f %.3f %d\n, a*100, a*100, (int)(a*100)); 9.99 10.000 9 Hasty unresearched guess: If you print with a large fp fmt (say 22.18) you will get a better idea of the value: 9.99403953552246 10.000 9 The %.3f says to round upward to inf after 3 decimal places, so 9. is rounded to 10.000. The %f defaults to round up after 6 decimal places, so 9.994 is rounded to 9.99. Everything is working. There are a lot of subtleties in floating-point printf(). Printing binary values out and reading them back accurately can be a non-trivial exercise. - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD or other BSD for no-MMU ARM processor ?
Hi, re: Does anyone know if there is a port of FreeBSD, or any of the other BSDs (e.g. NetBSD) for that matter, which will run on an ARM processor which does NOT have an MMU (Memory Management Unit)? The general feeling seems to be that without an MMU and the added features of memory protection it provides, the heavyweight process-oriented UNIX kernel doesn't really offer much advantage over a lighter-weight solution like RTEMS or eCos. The uClinux gang disagrees with this assessment, Another such light-weight embedded C kernel with unmapped ARM support that seems to be popular lately is microC/OS, sometimes called uC/OS or mucos. My _impression_ is that it is a free open source system but that a number of companies sell support and a number of embedded companies specialize in getting it past validation suites in vertical niche markets, etc.. I think it's been used for digital cameras and such. http://www.accu.org/bookreviews/public/reviews/m/m002257.htm http://www.cmpbooks.com/product/1057 - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: beastie boot menu, 4th (forth)
Hi, re the question from Roman Neuhauser [EMAIL PROTECTED] Fri, 9 Jan 2004: forth looks like it's an interesting .. language. Can anyone recommend good (or just any, really) introductory material? --- If you do want to get into Forth, you can probably find some of the following in a decent research library: * The common leading intro text to Forth was: Starting FORTH, Leo Brodie, FORTH, Inc., Prentice Hall, 1981. * Another good intro was: FORTH, W.P. Salerman, O.Tisserand, and B. Toulout, Springer-Verlag, 1983. * It's not a tutorial, but it may be helpful: FORTH Encyclopedia: The Complete FORTH Programmer's Manual, Mitch Derick and Linda Baker, 2nd ed., Mountain View Press, 1982. * Uneven, but potentially very good for the novice, Invitation to FORTH, Harry Katzan, Jr., PBI, 1981. * If nothing else, you should be able to find this influential introductory paper by an IBMer, which arguably played an important role in legitimizing Forth use: An Architectural Trail to Threaded-Code Systems, Peter M. Kogge, IEEE Computer, v.15,n.3, pp.22-32, March 1982. --- If you are used to any RPN language, such as found on an HP calculator, or Postscript, you will find getting into Forth rather easy (Although not the same, Forth and Postscript are very similar). It's not often described this way, but you can somewhat think of Forth as a stand-alone interactive threaded-code compiler backend, which you can program directly using the compiler's intermediate language and interact with the symbol table. Forth is at it's best when you have small (32K), unique embedded systems (perhaps with custom architecture) and have no existing toolchain. I think you could find a Forth in the ports tree to get up-to-speed with, before looking at boot-time FICL... Paul Frenger has a Forth column in SIGPLAN notices. For instance, the only published academic reference that I am aware of that describes PicoBSD is Forth and the FreeBSD Bootloader, Paul Frenger, ACM SIGPLAN Notices, August 2000, v.35,n.8, pp.15-17. I don't know how active this is, but there are many links: http://www.forth.org Forth seems to have become heavily used in spacecraft. The instrument platform on the US probe that landed on as asteroid awhile back was all Forth, if I understand correctly. Both US and USSR used Forth this way. See also: http://forth.gsfc.nasa.gov Reasonably impressive list... - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc problem/openoffice failure
Julian Elischer wrote: ... I have not been able to compile the openoffice port ... ... Has anyone else seen this? I tried to build openoffice on a clean -current system, built from a recent cvsup, and it failed to compile... This was perhaps a week and a half ago, kept meaning to get back and look at it, but time seems to have got the best of me. - bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sound drivers
Hi, Lev Serebryakov asked: I want to write sound driver for FreeBSD (pcm bridge driver) ... Is here any documentation about pcm architecture? I wrote a pcm audio driver and tried to document things somewhat in a largish comment block and some web page doc, you should be able to get the kit and doc from: http://alumni.cse.ucsc.edu/~brucem/geode.html Hope this helps, please let me know if you find something missing or bogus! - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Random disk cache expiry
For those thinking of playing with predictive caching (likely an area of considerable student endeveour/interest these days at both filesystem and web level): --- Matthew Dillon: So there is no 'perfect' caching algorithm. There are simply too many variables even in a well defined environment for even the best system heuristics to cover optimally. --- David Schultz: If that proves to be infeasible, I'm sure there are ways to approximate the same thing. The hard parts, I think, would be teaching the VM system to use the new information, and gathering statistics from which you form your hints. --- Right. It's easy if you know the complete future of the total system state, which of course you never will. Someone interested in this might try to apply the latest in machine learing techniques, classifiers, etc., to the online problem. Variants of this are receiving lots of attention in areas such as gene sequence prediction. I dunno, but it seems like a lot of the math ends up pretty similar to economics, and we all know how well those models work. Kind of funny, running an economic simulation in your kernel... but actually getting possible at some level, at least for research systems with modern machines. There was a time when you would be fired for putting floating-point in an OS. http://csl.cse.ucsc.edu/acme.shtml : Many cache replacement policies have been invented and some perform better than others under certain workload and network-topological conditions. It is impossible and sub-optimal to manually choose cache replacement policies for workloads and topologies that are under continuous change. We use machine learning algorithms to automatically select the best current policy or mixtures of policies from a policy (a.k.a expert) pool to provide an adaptive caching service. - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Random disk cache expiry
Hi, re: If a file's access history were stored as a hint associated with the file, then it would be possible to make better up-front decisions about how to allocate cache space. I believe at one time this was a hot area, and now maybe it is back. I vaguely recall a recent PhD in this area, you might want to contact him and get some up to date pointers (I think Tom Kroger spent some time at CMU looking at a lot of file access traces in this regard). I believe Tom modified a Linux filesystem to do just this and did a fair amount of benchmarking (which, of course, proved it (or at least his PhD ;) was useful)! In any case you might get some interesting starting refs if you are interested in this area... http://www.cse.ucsc.edu/~tmk/ http://csl.cse.ucsc.edu/prediction.shtml http://csl.cse.ucsc.edu/acme.shtml - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
re: anyone working on a new file system metaphor?
re filesystems indexing by content, etc: ... anyone working on a new file system metaphor? ... ... universal indexing system ... *any* file of *any* type in *any* location... Apologies (... by gum, we walked through feet, nay yards of snow...) * The very 1st issue of The Computer Journal in April 1958 has an article relevant to this: http://www3.oup.co.uk/computer_journal/hdb/Volume_01/Issue_01/ Automatic retrieval of recorded information, Fairthorn: http://www3.oup.co.uk/computer_journal/hdb/Volume_01/Issue_01/010036.sgm.abs.html * You might find Semantic File Systems, Gifford, et al., of interest: http://www.psrg.lcs.mit.edu/history/publications/Papers/sfsabs.htm http://www.informatik.uni-trier.de/~ley/db/conf/sosp/sosp91.html and anthing else calling itself a semantic filesystem: http://www.objs.com/survey/OFSExt.htm * For one place to start, look up Gerard Salton and related work. If you can find it, see his book: Automatic Text Processing: The Transformation, Analysis, and Retrieval of Information by Computer, Addison-Wesley, 1989. See also his SMART system (System for the Mechanical Analysis and Retrieval of Text). * Follow to journals such as JASIS, work in automatic indexing, digital library, and information science: http://www.asis.org/Publications/JASIS/jasis.html * This is all early work, there's been a lot lately, what with neural nets, etc.. Areas such as this, which have a feel of subjective quality, often seem much harder to get right than one would like. Also, overhead is inevitably high, and seems to always grow higher than feels right. So these systems become external-to-the-os databases. If in the OS, all too often it's like having a very non-deterministic database at the heart of your OS - not good. Maybe yours will be better! ... Perhaps you could extend locate (man locate)? http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/s/Salton:Gerard.html http://citeseer.nj.nec.com/cs?q=Gerard+Saltonsubmit=Search+Documentscs=1 http://www.cs.cornell.edu/Info/Department/Annual95/Faculty/Salton.html http://www.asis.org/Features/Pioneers/salton.htm Salton G., Automatic Text Analysis, Science, 1970, 168(3929):335-342. - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SanDisk/SunDisk Compact Flash CIS
This note might be common knowledge in some quarters (?), but I thought I'd post... I have 2 SanDisk 128M Compact Flash cards, superficially identical. The CIS info for one (purchased 3/4 months ago?) claims it is a SunDisk SDP and the other a SanDisk SDP (recently purchased). The /etc/defaults/pccard.conf file used to have a CIS entry for SunDisk SDP, but doesn't anymore (for either -stable or -current). To get both of these CFs to work with the same FreeBSD 4.6-stable system, I added the CIS info below. Can anyone elaborate ont this little story? --- /usr/src/etc/defaults/pccard.conf Wed May 15 23:18:21 2002 +++ /etc/defaults/pccard.conf Wed Nov 13 15:06:18 2002 @@ -267,9 +267,23 @@ iosize 16 # SunDisk Flash ATA -# (OEM: Epson Flash Packer) -card SunDisk /.*/ +# (SanDisk) +card SanDisk SDP + config 0x1 ata ? + insert echo SanDisk Insert + remove echo SanDisk Remove + +# SunDisk Flash ATA +# (SanDisk) +card SunDisk SDP config 0x1 ata ? + insert echo SanDisk Insert + remove echo SanDisk Remove + +# SunDisk Flash ATA +# (OEM: Epson Flash Packer) +#card SunDisk /.*/ +# config 0x1 ata ? # T-POWER Flash ATA card /T-POWER */ /.*/ The output of pccardc dumpcis for both CF devices, compared: --- bad_dumpcis.txt Wed Nov 13 14:50:20 2002 +++ good_dumpcis.txtWed Nov 13 15:02:57 2002 @@ -16,9 +16,9 @@ 000: 45 00 01 04 PCMCIA ID = 0x45, OEM ID = 0x401 Tuple #5, code = 0x15 (Version 1 info), length = 23 -000: 04 01 53 61 6e 44 69 73 6b 00 53 44 50 00 35 2f +000: 04 01 53 75 6e 44 69 73 6b 00 53 44 50 00 35 2f 010: 33 20 30 2e 36 00 ff - Version = 4.1, Manuf = [SanDisk], card vers = [SDP] + Version = 4.1, Manuf = [SunDisk], card vers = [SDP] Addit. info = [5/3 0.6] Tuple #6, code = 0x0 (Null tuple), length = 3 000: 14 08 00 - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sio i/o
FWIW, regarding direct user application access to I/O space, (a technique to be avoided if at all possible, but sometimes useful for those 1-hour emergency projects, see the question How do I directly access I/O devices from an application program (use in and out instructions)? In the picobsd FAQ at: http://alumni.cse.ucsc.edu/~brucem/pico_notes.htm http://www.cse.ucsc.edu/~brucem/pico_notes.htm It has an example program for FreeBSD 4.3. In short, open ``/dev/io''. Hold the handle for as short a period as possible. Include /usr/src/sys/i386/include/cpufunc.h - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
PCM Native Audio Driver for NatSemi Geode GX1
I have written a FreeBSD new PCM audio driver for the Native Audio PCI function internal to the National Semiconductor Geode GX1/Cx5530 CPU and chipset, and integrated equivalents. This driver uses the Cx5530 southbridge's internal PCI audio hardware directly. It does not use the Soundblaster emulator that at one time was in the Cyrix hypervisor. I'm under the impression that this driver should work on any NatSemi GX1 CPU, but don't know that for sure. Also included in this kit are 4 small new PCM audio test programs. These test programs should work with any FreeBSD new PCM audio driver. The kit can be obtained at: http://alumni.cse.ucsc.edu/~brucem/gx_audio This driver is heavily commented and hopefully is useful to anyone studying the FreeBSD PCM audio system, or any similar PCI drivers using interfaces built on FreeBSD kernel objects. All features exercised by the test programs are working. Testing has been done under FreeBSD 4.6 Stable. Suspend/Resume support is present but not yet tested. Please let me know if you find bugs or have any advice at all about anything pertaining to this... - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
