unsubscribe
unsubscribe rlate...@mwb.co.za To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.2-stable, panic #12
Matthew Jacob said: > > In terms of design reviews and architecture *before* the commit, well, if > you want to go that route I can assure you it's a major amount of work. It > will bring FreeBSD into "adult" development- no large scale project with > > 50 engineers really succeeds long term without it, but are you really > wanting to the tbings of: MRD (Market Requirement Document), External > Reference Spec, Internal Reference Spec, Test Plan, Architecture Review, > Implementation Review, *Commit*, Test, Release, Post Mortem Review. > Part of me totally agrees with this (and from the standpoint of being a generally responsible person) all in all do agree. The silly and fun part of me says that all of the fun and the somewhat disorganized nature of creativity should not be destroyed by imposing too many roadblocks in the way of that creativity. The key here is for those with the bottom line responsibility to make the tradeoff between the quality of their (actually the communities') product and making it fun to work on it. I suggest that biasing it slightly in the direction of fun would be best, but most strongly supporting fun and creativity in the areas that need the application of creativity and innovation the most. It seems that a practical aspect of the fun of creativity is for each individual developer to know enough about the work to realize what is reinvention vs. new invention. There have been alot of tradeoffs made in the design of the new (FreeBSD specific) portions of the code, and it isn't likely that those who did not participate directly in the work will know what decisions and tradeoffs were made. Even if the code had comments on every line, and there was a design document associated with every significant subsystem, it would be unlikely that the tradeoffs would be fully disclosed. Some of the tradeoffs made in the past might not be appropriate for now, but others might be quite critical for maintaining some of the positive qualities that FreeBSD is known for today. The above is the reason why gaining access to the decision making process of the past is a choice that allows the maximization of fun in the present, and doesn't loose the positive effects of past work. The negative effects of the creative process are mitigated by the experiences of developers who have alot of history in the field. Loosing that experience in the name of "fun" or even fixing problems that exist in the present will possibly (and in some cases will probably) regress the quality of the code in unintended ways. In a community project like FreeBSD, the notion of ego should really be left alone. The project is best served by the cooperative efforts of all those who are involved, and with ego and impatience being only a secondary or tertiary motivating factor, the group as a whole will benefit the most. The strongest effect that ego had on me when working on FreeBSD was the damage in my name, by me, done to the codebase. Even though there was too much experimental code added to the codebase at the time, there were few other choices available. Perhaps I tended to hold on to the old (hacking) ways too long, but I certainly realized that, and was working aggresively and great restraint to fix that insidious problem well before the time that I had quit the team. (Note that my work was progressing, but also being held away from the tree due to the need to maintain stability, both for altruistic reasons towards the project, and also due to the ego-issue of wanting to avoid breaking or regressing the code.) So, it seems that fun should be a side-effect of working on the project, but that fun should be responsible. Creativity is often associated with fun and enjoyment, and that should not be destroyed by imposing too many rules. I think that the key here is avoiding the negative aspects of ego, and instilling an ethic of responsibility. There are people's livelihoods dependent on the viability of FreeBSD, and fixing one set of problems and causing regressive side-effects in other areas is undesirable. Mitigating the negative side-effects by using available resources, both as an after the fact review aid, and more importantly: in conceptual reviews will maximize the aspects of fun, help mitigate regressions, and in the case of working earlier on with people who have made design decisions before, minimize the friction due to design corrections or reconsideration needed after the fact. No-one wants to redo their programming work, after reviews might be showing that initial design premises are wrong or incomplete. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re:
auth c0d77546 unsubscribe freebsd-hackers-digest rlate...@mweb.co.za
[no subject]
auth c0d77546 unsubscribe freebsd-hackers-digest rlate...@mweb.co.za
Fw:
- Original Message - From: Renier Lategan To: hack...@freebsd.org Sent: Saturday, June 05, 1999 9:53 AM auth c0d77546 unsubscribe freebsd-hackers-digest rlate...@mweb.co.za
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Matthew Dillon said: > > I don't want to be a pest, because this really shouldn't be on an > open forum. But John: I would ask you questions and the answers I > would get would be in the form: "Nobody understands that > code but me, don't touch what you don't understand", or "The algorithm > is obvious from the code". This in regards to non-compartmentalized > algorithms strewn across half a dozen source files which are almost > universally lacking in comments of any substance. > The frustration that I was showing was a result of off the wall assertions being made, with few coherent questions. Your questions are often analogous to someone saying that the VM code sucks, but will you help me with it, by teaching it to me? Oh, by the way, I haven't read the docs that you asked me to... :-). Hows about the frustration of being asked to review code "corrections" (or even seeing commits) that show a confusion that would have been cleared up if the docs were read, and then time was spent to ask questions that are backed with some initial understanding? > > That VM code was very fragile. It mostly worked, but it was very fragile. > It still IS fragile. > Are you trying to assert that the code is broken, and you will come in on your white horse and fix it? The minor fixes that should really be done are little in comparisons with the complexities and work associated with the original innovation. Actually, there is alot in the (VM) code that causes it to be generally robust. It is important to make sure that the code is well understood, or the various mechanisms that do provide for robust behavior in various loading conditions will be broken. (Randomly changing code that the hacker doesn't understand will indeed make code appear to be fragile.) The VFS code does need work, but it should be done only if the reasons and effects of its design are well understood by the individuals doing the work. There is a lot of infomation available, and it is available for the asking. The interface to filesystems and how they work need to be done from scratch. The need for backwards compatibility is probably gone now, and has been less important after the softupdates being integrated. There are two significant approaches to fixing the interface, and my suggestion is to eliminate the block-buffer interface all together. That was on my list, and really would have taken only a few weeks of work (and alot of review and testing.) I suggest design consultation before design and implementation however. Note that there are alot of individuals with biased views as to how to do I/O, and some of them have really good ideas. The key is to integrate what is needed for the I/O subsystems, and what is needed for filesystems. The caching per-se is already handled architecturally, so almost any work on vfs_bio beyond minor fixes for NFS are probably wasted effort on a legacy design that is less efficient than need be. On of the original passes for the merged VM buffer cache eliminated the buffers except for metadata, and the scheme worked. Since the need for backwards compatibility is almost gone, totally eliminating the buffer cache (and associated metdata bp-buffers) would be a good project. By elimintaing VFS_BIO, 99% of the grunge code would be eliminated from the VM/VFS code. Most of the ugliness in the VM code is there in order to interoperate with filesystems, and the methods used for them. If the vfs_bio rework is done, and done properly, the issues of coherency with VM and across VFS layers will be very clean to implement. In essense, this would be a forward moving project, which would avoid massive amounts of rework, and minimize breaking existing code. I suspect that re-architecting vfs_bio would be the best possible time investment. Continual re-working of the code, when it is used in ways that it wasn't even architecturally designed for (e.g. NFS, LFS), is more of an exercise in continual polishing. Note that the architectural issues regarding vfs_bio and NFS appeared way before the FreeBSD code, but have been problematical from day one. Note all of the hackery in the NFS code to make the buffer cache paradigm sort-of work... LFS is yet another beast that has work arounds to support a buffer cache scheme. Someone who wants to do something creative, with a user population that would be very thankful and that person wants to work on VM or VFS code, will consider carefully the straightforward effort to redesign VFS_BIO. If you want, I can have a working copy for you in a couple of weeks!!! :-). -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.2-stable, panic #12
At 10:13 AM +1000 6/5/99, Greg Black wrote:
>sth...@nethelp.no writes:
>
>> > "David E. Cross" writes:
>> >
>> > > fd=open(argv[1], O_CREAT, 600);
>> >
>> > Since this opens the file so that it cannot be written to, not
>> > to mention the really weird mode it will get if it's created by
>> > that open(), the rest of the thing doesn't deserve to work.
>>
>> That may be the case, but it shouldn't panic the machine.
>
>I did not suggest that it was a likely cause of the panic. I
>said that it's a fair thing for people who provide test code to
>at least make it correct so that other people don't have to
>waste their time on irrelevant issues. Of course, if it is the
>broken test code that provokes a panic, that should be stated up
>front as part of the test case.
let us see.
The SUBJECT of this threat is: 3.2-stable, PANIC NUMBER 12
It is the latest in a series of threads, all started by david,
which talked about previous PANICs that he has been grappling
with since a recent upgrade to FreeBSD (among other things).
I guess that was not upfront enough. I will have to chide david
for being so devious with the topics he posts to hackers.
More seriously, I expect you were trying to be helpful with your
code-review response, but you really did completely misread the
messages that David has been posting. It would be easier to just
admit that and forget about it, than to try and convince people
that your reply made ANY sense given the messages David has been
posting while tracking down this very vexing ("PANIC NUMBER 12")
problem that we (RPI) have been trying to pin down.
---
Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu
Senior Systems Programmer or dro...@rpi.edu
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
While on the topic: Who is working on devfs and why not? I'd like to know whether there is some interest in getting that work underway again. More than interested to help. > You're forgetting that devsw[] is another stopgap. The kernel should > probably use something like devfs, where dev_t's only exist for devices > that actually exist. xxx_init() is far too early to decide which hardware > devices exist. > > Bruce Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
On Sat, 5 Jun 1999 03:24:07 -0500 (EST) "John S. Dyson" wrote: > > I don't want to be a pest, because this really shouldn't be on an > > open forum. But John: I would ask you questions and the answers I > > would get would be in the form: "Nobody understands that > > code but me, don't touch what you don't understand", or "The algorithm > > is obvious from the code". This in regards to non-compartmentalized > > algorithms strewn across half a dozen source files which are almost > > universally lacking in comments of any substance. > The frustration that I was showing was a result of off the wall assertions > being made, with few coherent questions. Your questions are often > analogous to someone saying that the VM code sucks, but will you help me > with it, by teaching it to me? Oh, by the way, I haven't read the docs > that you asked me to... :-). Hows about the frustration of being asked > to review code "corrections" (or even seeing commits) that show a confusion > that would have been cleared up if the docs were read, and then time was > spent to ask questions that are backed with some initial understanding? I dunno, John. Matt's right on the ball here, from my experience. Vague non-answers seem to be your specialty. -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
> On Sat, 5 Jun 1999 03:24:07 -0500 (EST) > > > The frustration that I was showing was a result of off the wall assertions > > being made, with few coherent questions. Your questions are often > > analogous to someone saying that the VM code sucks, but will you help me > > with it, by teaching it to me? Oh, by the way, I haven't read the docs > > that you asked me to... :-). Hows about the frustration of being asked > > to review code "corrections" (or even seeing commits) that show a confusion > > that would have been cleared up if the docs were read, and then time was > > spent to ask questions that are backed with some initial understanding? > > I dunno, John. Matt's right on the ball here, from my experience. Vague > non-answers seem to be your specialty. > Rude, snide comments seem to be yours. I'm sorry that I haven't given you answers to every question that you might have asked, but I doubt that the motivation of your questions were in the best interests of everyone involved. The only way that I can reasonably give answers to questions is if the answer is really wanted. This is a continual problem where if I give an answer, it is often begged with another question that often shows that the real answer isn't desired. Almost anyone who as really asked me for help, and really wants the answer has gotten the answer. One good way to determine if an answer is really desired is to find out if the person who poses the question is willing to research the publically existant information (often the information is out in the open, and indexed in publically available databases.) Questions are often asked when the info is already out there -- it is always best to show people how to get their own answers. The best way that I can generally add to the information out there is to request that people call me, or if specific questions are asked after some effort in doing the research has be made. Sometimes questions are asked, and the correct answer isn't the one that is desired, and then the question is asked again to see if the answer has changed... Seldom do I need to change my answer, unless the question is different :-). John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
In message , Nick Hibma writes: > >While on the topic: Who is working on devfs and why not? > >I'd like to know whether there is some interest in getting that work >underway again. More than interested to help. I'm not currently working on devfs, but I am building the infrastructure it should be based on in the kernel. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Jason Thorpe wrote: > I dunno, John. Matt's right on the ball here, from my experience. Vague > non-answers seem to be your specialty. That appears to be a comment designed to create a flame war. It certainly is not helpful to FreeBSD. Please don't abuse our lists. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
> >While on the topic: Who is working on devfs and why not? > > I'm not currently working on devfs, but I am building the infrastructure > it should be based on in the kernel. Anymore information available on where you are with this? Cheers, Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
In message , Nick Hibma
writes:
> > >While on the topic: Who is working on devfs and why not?
> >
> > I'm not currently working on devfs, but I am building the infrastructure
> > it should be based on in the kernel.
>
>Anymore information available on where you are with this?
I currently have a kernel running where dev_t is a pointer to a
"struct dev" and where char and block devs are collapsed at the
dev_t level. There are some bogons i need to fumigate, but I'm
off to give a course in Stockholm much of this coming week, so
don't expect any commits just now. (I may actually postpone/abandon
this step for now, since some of the changes pulls rugs away which
cover what looks to me like holes in the floor).
Next is to integrate the dev_t anti-aliasing and vnode anti-aliasing
code.
When I have that bit down and done, the next step is for device
drivers to register individual dev_t's rather than blanket cdevsw
entries. The later ability will be retained for pseudo drivers
and other (pseudo)magic.
This registration will look pretty much like the current #ifdef'ed
DEVFS stuff, and in addition it will allow the driver to hang two
fields of the dev_t, typically a pointer to the struct softc and
maybe a unit number or something. This will obsolete all of
the magic minor -> {unit|softc} converters in our drivers and
make the "NFOO" configuration obsolete.
That is, as such the end of this little project, and where a future
DEVFS could take off from. Basically all that is needed for a DEVFS
to do, is to hook into the dev_t maintenance code and construct
the directory tree.
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Socket Problem in 3.2?
I'm willing to investigate this, but I need some pointers on where to start. There seems to be a socket-level problem with 3.x...I havent tested it in 3.1 yet but I do see it in 3.2. 2 Freebsd boxes connected back to back with a serial line..it happens to be a T3 but the results are the same with any PTP line..one is 2.2.8 and the other is 3.2. The 2.2.8 machine is pinging the 3.2 machine...the link is brought down. The 2.2.8 machine starts printing "sendto: network down" messages until the 3.2 machine is brought back up, and then pinging resumes normally. However, when pinging from the 3.2 machine, the 2.2.8 machine is brought down and the 3.2 machine just stops (no messages as if it doesnt detect the link down)then when the 2.2.8 machine is brought back up the ping does not resume. A new ping session from the 3.2 box works normally indicating the the link is working properly. It seems that something was done, perhaps to eliminate the "Sendto" messages that keeps applications from coming back up if the link goes down and comes back up. This is pretty bad if major network services exhibit the same behaviour. Anyone have any ideas? Dennis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard boot.flp for *plain* 3.2-RELEASE
In article <10710.928404...@peewee> j...@zippy.cdrom.com writes: >> JFYI, during our conversation, we identified the following areas in >> which we'd like to work together in enhancing sysinstall: >> >> 1. Put pccardd on the mfsroot floppy and add a few things to >>sysinstall (this may already be done by his patches, I haven't >>had time to check) which enable its use during installation. I want to commit it soon because this is long-awaited feature. I want to see the patches against -current. >> 2. Bring in message catalog and BIG5 support so that the standard >>installer supports English, Japanese, Korean and Chinese by >>default. AFAIK, Big5 means a coding system only for traditional Chinese widely used in Taiwan and Hong-Kong. EUC-jp (Japanese), EUC-kr (Korean), and Big5 (Traditional Chinese) occupies almost similar area in 16bit space. Our code can handle these three coding systems and maybe GBK (Simplified Chinese) coding system. I believe that our code also can handle ISO-8859-1 Latin charsets. I can prepare French, German, and many European boot.flp if there are translators for these languages. The messages and help/document files of 3.2-RELEASE have already been translated into Korean and are translating into Japanese. We need translator and maintainer of Chinese messages. >> 3. Figure out why I couldn't get the isc-dhcp client to work >>before 3.2's release (causing me to abandon the idea of adding >>this feature for 3.2) and get DHCP support into 3.3. We already have experimental code to activate WIDE-dhcp client. I'm not sure why isc-dhcp does not work. >> I look forward to working with Tatsumi-san on these features; >> they're all long overdue! :) I'm working on rewriting ugly parts of "2." on 3.2-RELEASE like I did for "1.". As far as I know, differences between src/release of 3.2-RELEASE and it of 4.0-CURRENT are very small. -- HOSOKAWA, Tatsumi Assistant Manager Information Technology Center, Keio University To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard boot.flp for *plain* 3.2-RELEASE
On Sun, 6 Jun 1999, HOSOKAWA Tatsumi wrote: > >> 3. Figure out why I couldn't get the isc-dhcp client to work > >>before 3.2's release (causing me to abandon the idea of adding > >>this feature for 3.2) and get DHCP support into 3.3. > > We already have experimental code to activate WIDE-dhcp client. I'm > not sure why isc-dhcp does not work. It isn't something as simple as not putting bpf into the install kernel is it? -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Man pages for review
I have written man pages for aio_write, aio_error, aio_return, aio_cancel, aio_suspend, and lio_listio. They are in my ~ on freefall if anyone would like to review them. I have also edited aio_read.2 and aio.h to correct minor problems, if you would like to review those as well. In particular, a review for accuracy and correct return values and diagnostics will be appreciated. aTdHvAaNnKcSe for your help. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
CVS repo shared via NFS, error?
Please bear with me if this is a FAQ, this is my first encounter with CVS. I'm trying to share a CVS repository via NFS. CVSup had no troubles to create an uptodate CVS repo. based on what is on the 3.1 CDs. This repo is on NFS server 'yedi'. I also have a NFS client 'p100': bash-2.02# cvs -R co -d . src cvs checkout: existing repository /cvsroot does not match /cvsroot/src cvs checkout: ignoring module src bash-2.02# cvs -R co -d . -r RELENG_3_2_0_RELEASE src cvs checkout: existing repository /cvsroot does not match /cvsroot/src cvs checkout: ignoring module src bash-2.02# ls /cvsroot/ .ctm_status distrib ports www CVSROOT doc src bash-2.02# mount /dev/da0s2a on / (local, writes: sync 8 async 105) /dev/da0s2f on /tmp (local, soft-updates, writes: sync 2 async 14) /dev/da0s2g on /usr (local, soft-updates, writes: sync 2 async 230) /dev/da0s2e on /var (local, soft-updates, writes: sync 55 async 304) procfs on /proc (local) yedi:/local/CVS-repository-base/CVS-repository on /cvsroot (read-only) bash-2.02# echo $CVSROOT /cvsroot bash-2.02# What does this error try to tell me? | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Major/Minor devices for i2o
Hi Y'll, Have not been hiding, just working on i2o stuff. Question: How to best map i2o devices to major and minor devices? Background: Currently, all i2o subsystem is handled by one driver. The driver collects i2o HRT and LCT data from all i2o IOPs and builds the appropriate tables. Translated to non-i2o English: The driver build a list of all i2o devices that are visible to the host (IOPs). Each controller builds a table of the controllers it controls (HRT) and of all the logical devices attached to these controllers (LCT). Problem: How do we map all these devices into major/minor? (It has to work on 2.2.8 as well as 3.x and 4.x, preferably with the same solution). Complications: * We need to be able to address individual IOPs (For example, each DPT controller is thre PCI devices and one IOP). * Each IOP has many physical devices (say 126 disks on each FCAL channel). * Each IOP has multiple levels of logical devices. * At most times the physical devices are not interesting, but at other times they are very interesting. Let me illustrate with a complex example: 2 DPT IOPs: 0 - 3 SCSI UW2 busses, each bus with 12 disks and two environmental controllers. 1 - Two FCAL channels, each with 112 drives and 8 environmental controllers. Disks are arranges as follows: On IOP-0 we have 17 RAID-1 arrays. These arrays are arranged as a RAID-0 with 18 strips in it. Two drives are hot spares. On IOP-0 we have 4 RAID-5 arrays (28 drives per array) arranged as a 4 stripe RAID-0. Looking at the physical devices attached we have: i0b0t0 through i0b2t15 (with t13, and t14 empty) i1bot0 through i1b1t113 (to make thing simple. This is already a problem as we have only 8 bits in the minor number. But wait, we also have logical views; one descrives the first level arrays (the RAID-1 and RAID-5, and a second that describes the second level array. Graphically, we have: disk0 disk1 disk2 disk3 ... diskN | | | | +--+--+ +--+--+ | | Array0 Array1... ArrayN | | +-+-+ | SuperArray0 ... SuperArrayN The i2o driver builds a series of tables and trees to represent this data. Ownership and availability are covered both as part of the i2o spec and as exportable data in the driver. The question is how to best express all this as major/minor numbers. Here are my proposals: Proposal 1: * Major numbers are converted to 16 bit quantities, and masked assignements are permitted. For example, the current major number continues to occupy the lower 8 bits, and a sub-major is allowed in the upper 8 bits. When assigning major numbers, only the lower 8 bits are considred, but the devswitch passes the entire 16 bits to the driver, after masking the upper bits for switching purposes. The driver uses the high bit (or some other bit) to differentiate character (raw) devices from block devices. Example; Major number 0x01fe means second IOP in the (old) major number 126. This will give us up to 16 IOPs. * Minor numbers also become 16 bit wide, 12 bits are used for the TID (Target ID, unique number identifying the I2O device on a given IOP). the upper 4 bits are reserved. This mapping allows for 16 IOPs, and a direct mapping of an i2o TID to a minor number. Proposal 2: * Major numbers are left alone. * The minor number is increased to 16 bits; 12 lower bits to map the TID, 4 upper bits to map the IOP. Again, we will have support for 16 IOPs and streight mapping of TID numbers. When moving to 3.x/4.x, I would recommend supporting the same plus, by default, using devfs to map the devices. For devfs, I suggest the following structure: /dev/i2o - The primary directory which contains all i2o entities. /dev/i2o/0-N - Each IOP gets its own directory. /dev/i2o/N/ctl - A file fo/from which control messages can be written, or IOCTL syscalls be made. /dev/i2o/N/data- If the IOP supports a single device (such as a simple network card), then this is the file representing that device normal data stream. /dev/i2o/N/xxT - For each found TID, a directory which name is the TID number. xx is a string representing the device class. See below. /dev/i2o/N/T/xxctl - Write/read to/from this file sends control messages and receives replies. IOCTL to this file does what one expects IOCTL to do. Control Files (ctl): Allow non-ioctl applications (such as shells) to interact, in a portable manner, with devices. It also bypasses the data length limitation of the IOCTL system call. Device Classes: I2O recognizes the following device classes. On the
Re: cdevsw_add
On Sat, 5 Jun 1999, Poul-Henning Kamp wrote:
> In message , Nick Hibma
> writes:
> > > >While on the topic: Who is working on devfs and why not?
> > >
> > > I'm not currently working on devfs, but I am building the infrastructure
> > > it should be based on in the kernel.
> >
> >Anymore information available on where you are with this?
>
> I currently have a kernel running where dev_t is a pointer to a
> "struct dev" and where char and block devs are collapsed at the
> dev_t level. There are some bogons i need to fumigate, but I'm
> off to give a course in Stockholm much of this coming week, so
> don't expect any commits just now. (I may actually postpone/abandon
> this step for now, since some of the changes pulls rugs away which
> cover what looks to me like holes in the floor).
>
> Next is to integrate the dev_t anti-aliasing and vnode anti-aliasing
> code.
>
> When I have that bit down and done, the next step is for device
> drivers to register individual dev_t's rather than blanket cdevsw
> entries. The later ability will be retained for pseudo drivers
> and other (pseudo)magic.
>
> This registration will look pretty much like the current #ifdef'ed
> DEVFS stuff, and in addition it will allow the driver to hang two
> fields of the dev_t, typically a pointer to the struct softc and
> maybe a unit number or something. This will obsolete all of
> the magic minor -> {unit|softc} converters in our drivers and
> make the "NFOO" configuration obsolete.
>
> That is, as such the end of this little project, and where a future
> DEVFS could take off from. Basically all that is needed for a DEVFS
> to do, is to hook into the dev_t maintenance code and construct
> the directory tree.
DEVFS has always meant to do exactly this.
there is already a place in the structure for these two fields,
and when devfs is running, the devsw[] table is not consulted.
The vnode already contains a direct pointer to the devsw entry and a
cookie (minor number), and these are called directly.
there is already a node type for the 'unified' device type.
there are three types of device in devfs
BDEV, CDEV and DDEV.
DDEV has only a pointer to teh methods and a cookie. (as you suggest
above)
>
> --
> Poul-Henning Kamp FreeBSD coreteam member
> p...@freebsd.org "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: cdevsw_add
Basically I'm not working on devfs at the moment since the bit that made it workable was ripped out with extreme prejudice by someone. I'm still absolutly convinced that a dynamic device registration and export framework is required in the long run, but I'm not fussed if it's based on the current devfs or an successor. I'd feel a bit happier about spending more time on it If I had any thought that the result would not be ripped out by the throat as soon as it works again, by a maniac that doesn't understand that it's a working subsystem (it was fully working at the time it was vandaliased but the nice fellow didn't even try it, and I got no warning except the commit message). There were two known problems that were based in other parts of the code (mfs and some vfs/module stuff) And the install software couldn't install with it. If PHK is working an a framework to make this easier, I'd love to get a white-paper on the topic because it's all unknown stuff at the moment. To get it going, you basically need to reverse the backout commits done by SOS a year ago. DEVSF itself works, but it needs a different disk subsystem to be able to represent dynamic disk partitions properly. julian On Sat, 5 Jun 1999, Nick Hibma wrote: > > >While on the topic: Who is working on devfs and why not? > > > > I'm not currently working on devfs, but I am building the infrastructure > > it should be based on in the kernel. > > Anymore information available on where you are with this? > > Cheers, > > Nick > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard boot.flp for *plain* 3.2-RELEASE
> It isn't something as simple as not putting bpf into the install kernel is > it? I'm afraid not. :) The symptom was that dhcp started up just fine, it just refused every lease offered by the server. Debugging stuff on the boot floppy is also kinda hard and the deadline was coming up so I had to put it on the 3.3 stack. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Man pages for review
Wes Peters scribbled this message on Jun 5: > I have written man pages for aio_write, aio_error, aio_return, > aio_cancel, aio_suspend, and lio_listio. They are in my ~ on > freefall if anyone would like to review them. I have also edited > aio_read.2 and aio.h to correct minor problems, if you would like > to review those as well. > > In particular, a review for accuracy and correct return values and > diagnostics will be appreciated. aTdHvAaNnKcSe for your help. hehehe, I'll take a look at it... probably better than what I did to the man page... :) -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
"Link Your Web Site" To IndustrySearch.Com
Increase traffic to your company's web site with a FREE Hyperlink to IndustrySearch.Com. Thousands of industrial purchasing agents, buyers, engineers and others searching for suppliers and services can locate your business easily with our USA Industrial Directory. You can visit IndustrySearch.Com at http://industrysearch.com "Link Your Web Site" to our USA Industrial Directory Data Base today! Visit IndustrySearch.Com at http://industrysearch.com and click on "Link Your Web Site" Thank you, K. Prater USA INDUSTRIAL DATA BASE MANAGEMENT To be removed from our mailing list, please click Reply and type "REMOVE" in the subject field To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard boot.flp for *plain* 3.2-RELEASE
In Sun Jun 6 00:32:29 1999, hosok...@itc.keio.ac.jp said: [...] :AFAIK, Big5 means a coding system only for traditional Chinese widely :used in Taiwan and Hong-Kong. :EUC-jp (Japanese), EUC-kr (Korean), and Big5 (Traditional Chinese) :occupies almost similar area in 16bit space. Our code can handle :these three coding systems and maybe GBK (Simplified Chinese) coding :system. I believe that our code also can handle ISO-8859-1 Latin :charsets. I can prepare French, German, and many European boot.flp if :there are translators for these languages. :The messages and help/document files of 3.2-RELEASE have already been :translated into Korean and are translating into Japanese. We need :translator and maintainer of Chinese messages. Count me in, I know there was a folk(maybe j...@csie.nctu.edu.tw) had hacked the source under http://wing-yee.ntc.keio.ac.jp/hosokawa/FreeBSD-boot/ and make 2.2.5-RELEASE have a chinese boot.flp. But jdli seems to have no free time to spend on this anymore :< I think I can take it. Cheers, -Foxfair. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Man pages for review
Christopher Sedore wrote: > > Sorry to be obtuse, but how would I read these? I tried various > derivations of http://freefall.cdrom.com/~wes, ~wpeters, etc. Oops, sorry. They're available now via the web, try: http://www.freebsd.org/~wes Maybe I'll get around to writing a index.html now that I have a "web presence" there. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Socket Problem in 3.2?
Dennis writes: > I'm willing to investigate this, but I need some pointers on where to start. > > There seems to be a socket-level problem with 3.x...I havent tested it in > 3.1 yet but I do see it in 3.2. > > 2 Freebsd boxes connected back to back with a serial line..it happens to be > a T3 but the results are the same with any PTP line..one is 2.2.8 and the > other is 3.2. > The 2.2.8 machine is pinging the 3.2 machine...the link is brought down. > The 2.2.8 machine starts printing "sendto: network down" messages until the > 3.2 machine is brought back up, and then pinging resumes normally. > > However, when pinging from the 3.2 machine, the 2.2.8 machine is brought > down and the 3.2 machine just stops (no messages as if it doesnt detect the > link down)then when the 2.2.8 machine is brought back up the ping does > not resume. A new ping session from the 3.2 box works normally indicating > the the link is working properly. I know that there were some changes/fixes to "ping" recently relating to this... you might want to check the CVS logs for clues. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Partitioning a freebsd partition on the fly
In article <19990601131050.a27...@falcon.sourcee.com>, Evan Tsoukalas wrote: > My question is, can I shrink my /usr partition down without losing > what is on it? It is a 3.8 gig partition that only has 900 meg or > so on it. I would like to trim about a gigabyte off of it so that > I can install Windoze. Is this going to be possible, or should I > start from scratch installing Winoze first? The only way to shrink it is like this: * back up the filesystem to someplace using dump * shrink the partition * run newfs to create a filesystem on the resized partition * restore the data from your backup John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: where is variable edata defined ?
In article <000201beacec$98086960$85343...@k>, fretre wrote:
> The variable such as _edata, _etext,_gdt are defined in the
> file asnames.h(/usr/include/machine/asnames.h),but
> 1. Where is the file that the variable such as edata,etext,gdt
>are defined in? and
I don't know about gdt. But edata and etext are provided
automatically by the linker ("ld").
John
--
John Polstra j...@polstra.com
John D. Polstra & Co., Inc.Seattle, Washington USA
"Self-interest is the aphrodisiac of belief." -- James V. DeLong
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard boot.flp for *plain* 3.2-RELEASE
In article <3759e1212f8.6009foxf...@news.ks.edu.tw> foxf...@news.ks.edu.tw writes: >> Count me in, I know there was a folk(maybe j...@csie.nctu.edu.tw) had >> hacked the source under >> http://wing-yee.ntc.keio.ac.jp/hosokawa/FreeBSD-boot/ >> and make 2.2.5-RELEASE have a chinese boot.flp. But jdli seems to have >> no free time to spend on this anymore :< I think I can take it. Thank you. Now I'm working on updated sysinstall messages. I'll send the URL of message.lt_EN, *.TXT, *.hlp files to translate when I finished this work. I want translators to other languages. -- HOSOKAWA, Tatsumi Assistant Manager Information Technology Center, Keio University To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
