From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Sat, 4 Sep 93 07:13:09 EDT Subject: Linux-Misc Digest #93 Linux-Misc Digest #93, Volume #1 Sat, 4 Sep 93 07:13:09 EDT Contents: *** PLEASE READ THIS BEFORE POSTING *** (misc-2.03) (Ian Jackson) Re: NT versus Linux (Kevin Brown) Re: NT versus Linux (Kevin Brown) Re: Ian Jackson (Lars Wirzenius) NCR5380 generic driver code, ALPHA T128/128F/228 SCSI driver (Drew Eckhardt) ---------------------------------------------------------------------------- From: ijackson@nyx.cs.du.edu (Ian Jackson) Subject: *** PLEASE READ THIS BEFORE POSTING *** (misc-2.03) Date: Sat, 04 Sep 1993 10:03:01 GMT Please do not post questions to comp.os.linux.misc - read on for details of which groups you should read and post to. If you have a question about Linux you should get and read the Linux Frequently Asked Questions with Answers list from sunsite.unc.edu, in /pub/Linux/docs, or from another Linux FTP site. In particular, read the question `You still haven't answered my question!' The FAQ will refer you to the Linux HOWTOs (more detailed descriptions of particular topics) found in the HOWTO directory in the same place. Then you should consider posting to comp.os.linux.help - not comp.os.linux.misc. Note that X Windows related questions should go to comp.windows.x.i386unix. The FAQ for this group is available on rtfm.mit.edu in /pub/usenet/news.answers/Intel-Unix-X-faq. Comments on this posting are welcomed - please email me ! -- Ian Jackson (urgent email: iwj10@phx.cam.ac.uk) 35 Molewood Close, Cambridge, CB4 3SR, England; phone: +44 223 327029 ------------------------------ Crossposted-To: comp.os.ms-windows.advocacy From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: NT versus Linux Date: Sat, 4 Sep 1993 05:37:55 GMT In article <930830.082811.4Z3.rusnews.w165w@mulvey.com> rich@mulvey.com (Rich Mulvey) writes: >muts@compi.hobby.nl (Peter Mutsaers) writes: > >>>> On Thu, 26 Aug 1993 02:27:00 EDT, rich@mulvey.com (Rich Mulvey) >>>> said: >> >> RM> folks? It's a for-profit company. They exist solely to make >> RM> money. What's the best way to make money? Kill your >> RM> competition, *especially* if they have a better product. Even >> RM> if they don't. What exactly does morality have to do with this? >> RM> Saying that they are 'evil' is basically saying that people >> RM> shouldn't strive to be successful. Gee, maybe we all should >> RM> spend the rest of our lives flipping burgers for each other. >> RM> But make sure that we avoid trying to provide a decent standard >> RM> of living for our families. >> >> RM> That would be moral by your logic, right? >> >> Yes, but they go too far. In the end it will damage themselves, like >> IBM was damaged too by the almost-monopoly they got in the 70s. First >> they get big profits, but the losses will be even bigger. > > If they damage themselves, that's *their* problem. New companies >will spring up to fill the void - just as it has always happened. And >*those* companies will probably be lean and mean at first, until *they* >kill themselves with bloat. That's the way that capitalism works. Which is true of the dynamics of companies within capitalism. But we're not really concerned about the companies so much as we are about the *products*. Let's take a look at two cases where the company in question was large, had an inferior product, and managed to have that product get real popular anyway due to the stupidity of the public. Case 1 is, of course, IBM. They came out with the PC. When it first came out, there wasn't much that was widely available that competed with it. Because it was an IBM product, *everyone* bought it. The PC gained most of its ground because people naturally thought IBM was good stuff. Little did they know that the product was actually quite badly designed, making use of a badly-designed CPU and a badly-designed bus (and a badly-designed DMA scheme, etc). Now look where we are today. What's the most popular type of computer? A PC clone. What kind of hardware is it? It's running a relatively broken CPU like the 486, something that has an instruction set and register set that leaves quite a bit to be desired, and running the *same* broken bus architecture that is responsible for the low performance of most of the hardware available for it. But because clones are so cheap, they're popular, and as a result people spend a great deal of time developing software for this broken hardware. Linux is a *perfect* example. I'm glad it happened, but I wish it had happened to better hardware. Case 2 is, of course, Microsoft. They came out with DOS for the IBM PC. Because people initially bought lots of IBM PC's, DOS became popular. Not on its technical merits (DOS has none), but on the IBM name. Because of this, people wrote programs for this broken "operating system", which caused it to become more popular, etc... Now look at where we are today. What's the most popular "operating system" available today? DOS, of course. Guess what needs it to run? Windows. We all know how badly broken and inferior DOS is. Yet, because it's so popular (due to the stupidity of the public), there are a lot of things that won't run under anything *but* DOS. Because people often do things that only one or two applications can provide the functionality for, they are often *forced* to run DOS, ugly as it is. Word processing is a perfect example. Lots of people have Wordperfect for DOS. Despite *its* brokenness, it's also one of the most popular things around. But to run it, you have to run DOS. Even if Microsoft were to go bankrupt *now*, DOS will be with us for a long, long time because it takes a long, long time to unwind the recursive dependency cycle which is behind the popularity of DOS. There are more examples, e.g. System Vr4, but I trust my point is clear: it doesn't matter *how* well a company may be doing in the future, the problems that they've left us with will cost us dearly, *exactly* as is happening now. An outside observer who wasn't really on the inside of all this might easily conclude that people in general *prefer* inferiority. This, of course, isn't really true. The biggest problem is that most people aren't bright enough or well-trained enough to recognize an inferior product when they see it, so they base their decision on things like how much it will cost or how much "support" they'll get (when, of course, few people realize that the promise of "support" for a product usually simply means that there will be someone on the other end of the telephone telling them that the bug they're reporting doesn't exist, hasn't been heard of before, and is being fixed even as they speak). >> Every company must fight its competitors, I agree; but they must also >> learn self-control. If you kill everyone you get an unhealthy >> situation, bad for everyone. > > But you just said that they are going to kill themselves as well, so >what's the problem if they will eliminate themselves as players in the >game? They'll leave us all with a legacy of inferiority. >> The former eastern-block was a >> monopolized economy, the results are clear. Microsoft is evil in a >> way, but more so, the buyers are stupid. They fall in a trap with >> opened eyes. Blinded by the lies and marketing stories of Microsoft, >> and too incompetent to judge the different choices on their technical >> merits. There are too many incompetent people on decision-making positions >> in companies, especially in automation departments. > > I have no sympathy for stupid/ignorant people. If they make decisions >about software and hardware without doing the proper research, they >deserve what they get. It is their responsibility. If a person is so >clueless that they think a salesman's sole interest isn't in padding his and >his company's pockets, and actually *believe* what the salesman tells them, >they shouldn't be making purchasing decisions. Yeah, but they usually *are* making purchasing decisions. >And if, as often happens, >the company fails because of poor decision-making, then we're only seeing >natural selection in action. Which, in the end, is a *good* thing. Agreed with respect to companies. But see above for why the process itself yields suboptimal results compared to making the correct choices to begin with. Additionally, you know what will happen, right? When Microsoft (or whoever) goes down, their product will eventually be replaced with another inferior product. >- Rich -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ Crossposted-To: comp.os.ms-windows.advocacy From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: NT versus Linux Date: Sat, 4 Sep 1993 06:07:50 GMT In article <930902.011749.7z2.rusnews.w165w@mulvey.com> rich@mulvey.com (Rich Mulvey) writes: >muts@compi.hobby.nl (Peter Mutsaers) writes: > >>>> On Mon, 30 Aug 1993 08:28:11 EDT, rich@mulvey.com (Rich Mulvey) >>>> said: >> >> > RM> That would be moral by your logic, right? >> > >> > Yes, but they go too far. In the end it will damage themselves, like >> > IBM was damaged too by the almost-monopoly they got in the 70s. First >> > they get big profits, but the losses will be even bigger. >> >> RM> If they damage themselves, that's *their* problem. New companies >> RM> will spring up to fill the void - just as it has always happened. And >> RM> *those* companies will probably be lean and mean at first, until *they* >> RM> kill themselves with bloat. That's the way that capitalism works. >> >> No, in the meantime a lot of damage will be done. It's not like in the 60s, >> when there were still hardly any alternatives. But now there are perfectly >> fine and well-designed operating systems with pretty wide acceptance. > > Exactly what alternatives? We're talking about Joe Average Small >Businessman who wants software to run on his computer without having to learn >a lot. He does not want, nor can he afford, NextStep, Unix, or anything >of the same ilk. MS-DOS is just about *perfect* for those needs. And Windows >adds to the value of the system he is getting without adding appreciably to >what he has to learn. Remember that people on the net tend to look at >computers as interesting unto themselves - the vast majority of computers users, >however, look at them as necessary evils. Quite so. However, *someone* has to design and write the software to run under these broken operating systems. If the operating systems in question were *decent*, the software authors would have a much easier time of it, which means quicker time to market, higher quality, and greater capability. The reason people generally can't afford Unix is that Unix is expensive. Why is it expensive? Because until recently, AT&T had a *monopoly* on it, and dictated the price of it through their licensing structure. Now BSDI has entered into the picture, but they're pricing their product more or less the same because that particular market is willing to bear the cost, and it's too late to make significant penetration into the general computing world, thanks to Microsoft. People aren't interested in NextStep because it is too resource-intensive and is *way* too late hitting the market. Something like that should have hit the market a few months after the PC hit the market. Of course, that wouldn't have been possible, because at that point the hardware was *even more* broken than it is now. > Technical excellence in software or hardware has *never* been a reason for >the consumer to go with a particular product. People buy Microsoft products >because they are relatively cheap, easy to use, and available. Yup. But technical excellence and low cost are not mutually exclusive! Just look at Linux if you want an example. Or look at the Amiga. >> Indeed. I hope for that. The sooner the better. That's my whole point. Of >> course they kill themselves only if people, as a result of their stupidness, >> refuse to be dictated by Microsoft, and make NT flop. > > You seem to be trying to justify your arguments on the grounds that they're >what the world should be. The problem is, people are perverse - they do >many, many things that are self defeating, destructive, and generally >stupid. You can make a very easy choice - stick with the elegant systems >and starve, or do what it takes to put bread on your table. This sums it up nicely. Yup, the *reason* things are the way they are is that people are generally stupid. Well, they get what they deserve, but unfortunately (because of that last thing you noted) they take the rest of us down with them!! We all know the truth of this, and most of us think it's totally wrong. Thus the intense hatred towards Microsoft. I don't necessarily hate Microsoft. I think they're a bunch of incompetent fools who are only good at one thing: taking maximum advantage of a stupid and gullible public. >> This is very easy because alone for >> techincal reasons there is no reason at all to use a Microsoft 'operating >> system'. > > Just keep saying to yourself "Cheap... easy... supported." Cheap...perhaps, but not as cheap as Linux. Easy? Perhaps, but others will probably say otherwise. Supported? What most people think of as being "support" is a total joke, and Microsoft does a bad job of supplying even *that*. And, of course, people are stupid enough to *pay* for that kind of non- support. >Technical >reasons are irrelevent to the average person. Once you learn that, you'll >be fine. :-) Already know it. Already know that people are so incredibly stupid that *they* will probably be the cause of my death (want proof? Try driving on the freeway and observing the "accidents", which are just the result of incredible stupidity in action, that happen). >- Rich -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) Crossposted-To: comp.os.linux.help Subject: Re: Ian Jackson Date: 4 Sep 1993 13:58:42 +0300 [ Please note: this article is not offering help to other people, so I'm crossposting and redirecting followups to comp.os.linux.misc ] whart@cis.ohio-state.edu (william d hart) writes: > This situation is typical of what a linux/usenet "newby" faces. > The newby (as a veteran of U.S. Army I find this term very offensive > as it means someone who isn't qualified to wipe his own ass > this in itself indicates the attitude of the "gurus" who use > this kind of terminology) is neck deep in linux looks here for help > and is either flamed to death or reads 60 copies of "figure it out for > yourself dummy" posts in the form of the daily posting. Flaming people to death is very rarely the proper thing to do. Wanting people to look at documentation specially prepared for people who are new at a subject before posting their questions is, however, not a Bad Thing. The point is this: anyone who has read a popular Usenet group for a while, will notice that some things come up very, very often. In some groups the same question is asked a dozen times during one week. This leads directly to two problems: the number of articles grows so big that few people bother to read most of them, and the people who know things and would like to answer questions become tired of answering the same question over and over again. After there exists FAQs and other documentation (as it does for Linux), the problem is that so many people don't know about it. Hence the FAQs (at least) are posted periodically. In popular groups, such as the Linux ones, posting the FAQs once a month is not enough: too many new people join the group with no knowledge of the FAQs and start asking questions already answered by them. Hence a more frequent periodic post that informs people about the FAQ. The frequency of the pointer post depends on many factors; for the Linux groups, empiric evidence states that once a week is too little but once a day works fairly well. > The solution is an attitude adjustment for the gurus IMHO, the solution is an attitude adjustment for the people who think other people are on Usenet to solve their problems. > (as in the usenet isn't your private domain so don't bitch at me > when I step in it) Usenet isn't anybody's private domain, so being a little polite and not wasting other people's time and money on is to be expected from everyone. > (maybe even leave your workstation for around half an hour, go outside, > (don't worry the sun won't hurt you (triple nested comments does this > qualify me for geek of the month)) breathe the fresh air and look > at the other people going about there business) Maybe even forget about yourself and realize that other people find the newsgroups much more worth the time reading them takes when there is less repetition. > and maybe turning the daily post into a polite weekly post. And maybe remembering that a (polite? I don't know) weekly post didn't do much about the number of repeated questions, but that the daily posting did marvels. BTW, here's how "The New Hacker's Dictionary" defines newbie: newbie /n[y]oo'bee/ n. [orig. from British public-school and military slang variant of 'new boy'] A USENET neophyte. This term surfaced in the newsgroup talk.bizarre but is now in wide use. Criteria for being considered a newbie vary wildly; a person can be called a newbie in one newsgroup while remaining a respected regular in another. The label newbie is sometimes applied as a serious insult to a person who has been around USENET for a long time but who carefully hides all evidence of having a clue. See BIFF. From this definition, I see no indication that newbie is all that offensive (ignorance, unlike stupidity, is not offensive). Likewise, most of the time I do not find the term used in a derogatory sense on Usenet. I am, of course, rather an amateur at English (it's the third language I learned) so I could be wrong. -- Lars.Wirzenius@helsinki.fi (finger wirzeniu@klaava.helsinki.fi) MS-DOS, you can't live with it, you can live without it. ------------------------------ Crossposted-To: comp.os.linux.development From: drew@kinglear.cs.colorado.edu (Drew Eckhardt) Subject: NCR5380 generic driver code, ALPHA T128/128F/228 SCSI driver Date: Sat, 4 Sep 1993 10:57:56 GMT I was contracted by Yggdrasil computing to do a device driver for the Trantor T128 SCSI boards often bundled with CDROMs, and it's now ready for alpha test. Obviously, owners of Trantor SCSI boards (T128,128F,228) will be interested in this, owners of other NCR5380 based boards (such as the PAS16 with SCSI port) might want to take a look at it since the heart of it is an easily adaptable generic NCR5380 driver, and developers may be interested in some of the design descisions I made. If you fall into any of these groups, read on. I'd rather spend my time finishing a rewrite of the SCSI FAQ (the FAQ people want to call these things "HOW TOs", I'll call it a FAQ because it's only the questions I spend far too much time answering), doing some benchmarking, and hacking code than handholding. There are also some environments that I don't have access to, so I'd like some feedback from testing in those environments. I want alpha testers who - Will patch the pl12 kernel and compile it themselves - Can live with the fact that the autoprobe probably won't work for them until they come up with a BIOS signature, which they'll mail to me. - Won't bitch at me if it doesn't work for them, and if it doesn't are willing to play with the various debugging controls to see where it isn't working. - Are willing to run a few benchmarks for me. I'm really interested in how different parameters on the queue handling affects performance. I've observed a 20-30% performance increase on reads (the change to writes is negligible) if I allow two commands per LUN to be outstanding (ie, to have propogated to the lowest driver level). I'm really interested in seeing how this affects faster devices (the drive I used was interleaved 3:1, giving a 330K/second head rate), and SCSI-II devices supporting tagged queueing where commands can propogate all the way to the device. If you can't fit these criteria, please wait for the public release. Testers that are especially welcome include - People with multiple SCSI devices - People with SCSI-II devices (the code supports SCSI-II tagged queing) Design things, with quotes from the comments : Often autoprobe routines screws up, so (Thanks to Pat Mackinlay for the Seagate driver command line override patches, without them I wouldn't have thought about letting the user configure the driver at boot time) * The card is detected and initialized in one of several ways : * 1. Autoprobe (default) - since the board is memory mapped, * a BIOS signature is scanned for to locate the registers. * An interrupt is triggered to autoprobe for the interrupt * line. * * 2. With command line overrides - t128=address,irq may be * used on the LILO command line to override the defaults. * * 3. With the T128_OVERRIDE compile time define. This is * specified as an array of address, irq tupples. Ie, for * one board at the default 0xcc000 address, IRQ5, I could say * -DT128_OVERRIDE={{0xcc000, 5}} * * Note that if the override methods are used, place holders must * be specified for other boards in the system. * Design * Issues : * * The other Linux SCSI drivers were written when Linux was Intel PC-only, * and specifically for each board rather than each chip. This makes their * adaptation to platforms like the Amiga (which uses the same WD/AMD * SCSI chip as the 7000FASST) more difficult than it has to be. * * Also, many of the SCSI drivers were written before the command queing * routines were implemented, meaning their implementations of queued * commands were hacked on rather than designed in from the start. * * Finally, when I designed the Linux SCSI drivers I figured that * while having two different SCSI boards in a system might be useful * for debugging things, two of the same type wouldn't be used. * Well, I was wrong and a number of users have mailed me about running * multiple high-performance SCSI boards in a server. * * This driver attempts to address these problems : * This is a generic 5380 driver. To use it on a different platform, * one simply writes appropriate system specific macros (ie, data * transfer - some PC's will use the I/O bus, 68K's must use * memory mapped) and drops this file in their 'C' wrapper. * * As far as command queueing, a pair of queues are maintained for * each 5380 in the system - commands that haven't been issued yet, * and commands that are currently executing. This means that an * unlimited number of commands may be queued, letting more commands * propogate from the higher driver levels giving higher througput. * Note that both I_T_L and I_T_L_Q nexuses are supported, allowing * multiple commands to propogate all the way to a SCSI-II device * while a command is allready executing. * * To solve the multiple-boards-in-the-same-system problem, * there is a separate instance structure for each instance * of a 5380 in the system. So, mutliple NCR5380 drivers will * be able to coexist with appropriate changes to the high level * SCSI code. * * Issues specific to the NCR5380 : * * When used in a PIO or pseudo-dma mode, the NCR5380 is a braindead * piece of hardware that requires you to sit in a loop polling for * the REQ signal as long as you are connected. Some devices are * brain dead (ie, many TEXEL CD ROM drives) and won't disconnect * while doing long seek operations. * * The workarround for this is to keep track of devices that have * disconnected. If the device hasn't disconnected, for commands that * should disconnect, we do something like * * while (!REQ is asserted) { sleep for N usecs; poll for M usecs } * * Some tweaking of N and M needs to be done. An algorithm based * on "time to data" would give the best results as long as short time * to datas (ie, on the same track) were considered, however these * broken devices are the exception rather than the rule and I'd rather * spend my time optomizing for the normal case. * * Architecture : * * At the heart of the design is a corroutine, NCR5380_main, * which is started when not running by the interrupt handler, * timer, and queue command function. It attempts to establish * I_T_L or I_T_L_Q nexuses by removing the commands from the * issue queue and calling NCR5380_select() if a nexus is not * established. * * Once a nexus is established, the NCR5380_information_transfer() * phase goes through the various phases as instructed by the target. * if the target goes into MSG IN and sends a DISCONNECT message, * the command structure is placed into the per instance disconnected * queue, and NCR5380_main tries to find more work. If USLEEP * was defined, and the target is idle for too long, the system * will try to sleep. * * If a command has disconnected, eventually an interrupt will trigger, * calling NCR5380_intr, which will inturn call NCR5380_reselect * to restablish a nexus. This will run main if necessary. * * On command termination, the done function will be called as * appropriate. * * SCSI pointers are maintained in the SCp field of SCSI command * structures, being initialized after the command is connected * in NCR5380_select, and set as appropriate in NCR5380_information_transfer. * Note that in violation of the standard, an implicit SAVE POINTERS operation * is done, since some BROKEN disks fail to issue an explicit SAVE POINTERS. To get other NCR5380 boards (ie, SCSI PAS16's, etc) supported, you write a couple of macros and do a #include "NCR5380.c" in a wrapper file /* * Using this file : * This file a skeleton Linux SCSI driver for the NCR 5380 series * of chips. To use it, you write a architecture specific functions * and macros and include this file in your driver. * * These macros control options : * PSEUDO_DMA - if defined, PSEUDO DMA is used during the data transfer phases. * * REAL_DMA - if defined, REAL DMA is used during the data transfer phases. * * SCSI2 - if defined, SCSI-2 tagged queing is used where possible * * USLEEP - if defined, on devices that aren't disconnecting from the * bus, we will go to sleep so that the CPU can get real work done * when we run a command that won't complete immediately. * * Note that if USLEEP is defined, NCR5380_TIMER *must* also be * defined. * * Defaults for these will be provided if USLEEP is defined, although * the user may want to adjust these to allocate CPU resources to * the SCSI driver or "real" code. * * USLEEP_SLEEP - amount of time, in jiffies, to sleep * * USLEEP_POLL - amount of time, in jiffies, to poll * * These macros MUST be defined : * NCR5380_local_declare() - declare any local variables needed for your transfer * routines. * * NCR5380_setup(instance) - initialize any local variables needed from a given * instance of the host adapter for NCR5380_{read,write,pread,pwrite} * * NCR5380_read(register) - read from the specified register * * NCR5380_write(register, value) - write to the specific register * * NCR5380_implementation_fields - additional fields needed for this * specific implementation of the NCR5380 * * Either real DMA *or* pseudo DMA may be implemented * REAL functions : * NCR5380_REAL_DMA should be defined if real DMA is to be used. * NCR5380_dma_write_setup(instance, src, count) - initialize * NCR5380_dma_read_setup(instance, dst, count) - initialize * NCR5380_dma_residual(); - residual count * * PSEUDO functions : * NCR5380_pwrite(instance, src, count) * NCR5380_pread(instance, dst, count); * * If nothing specific to this implementation needs doing (ie, with external * hardware), you must also define * * NCR5380_intr * NCR5380_queue_command * NCR5380_reset * NCR5380_abort * * to be the global entry points into the specific driver, ie * #define NCR5380_queue_command t128_queue_command. * * If this is not done, the routines will be defined as static functions * with the NCR5380* names and the user must provide a globally * accessable wrapper function. Comments concerning the code and discussion of the cleanest method for multi-instance support in the higher level code are welcome, whining and flames to /dev/null. I'll mail a copy of the code to anyone who responds in e-mail, but don't want to do a full public distribution at this point because I only want testers who don't need handholding, and are willing to run a few benchmarks. Distributing the patches in email means I can send updates out without effort, and can stay in close contact with the people running benchmarks for me. -- Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Drew Eckhardt, Condemn Colorado for Amendment Two. | Profesional Linux Use Linux, the fast, flexible, and free 386 unix | Consultant Will administer Unix for food | drew@cs.Colorado.EDU ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.misc) via: Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Misc Digest ******************************