RE: Electric fence usage
As long as your program isn't overstepping memory boundaries nothing should happen. What were you expecting? -Original Message- From: Miguel Mendez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 09, 2002 8:38 AM To: [EMAIL PROTECTED] Subject: Electric fence usage Hi, I've installed the electric fence port and it says that to use it you just -lefence, but it seems to me that this does nothing at all, at least for the little test programs that I've written. Is something else needed on FreeBSD to use it? Thanks in advance, -- Miguel Mendez - [EMAIL PROTECTED] EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: C++ to C translator
The original Stroustrop ATT C++ complier called cfront was a front-end C compiler. They may have it available at research.att.com. It's missing some things, though, like generic container classes. -Original Message- From: Rayson Ho [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 03, 2001 9:45 PM To: [EMAIL PROTECTED] Subject: C++ to C translator Hi, I have written some code in C++. However, I want to run it on an old mainframe machine, which a C++ compiler is not available. I know that the old g++ is a C++ to C compiler. Does anyone know which version it is? Also, anyone knows other C++ to C compilers? Thanks, Rayson __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: kERNEL
What on Earth are you talking about? -Original Message- From: Rafael Gomez [SMTP:[EMAIL PROTECTED]] Sent: Friday, March 17, 2000 07:10 To: FreeBSD Hackers Subject: kERNEL Can any of you send me a copy of a text kernel file? Rafael Gomez [EMAIL PROTECTED] Pager: [EMAIL PROTECTED] Charter Communications International Venezuela Tel: 58-2-576.60.80 Fax: 58-2-572.43.43 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Reading the kernel sources
Get a copy of the 4.4BSD book and read the relevant code along with the various topics. "Of course you're the Messiah! I say you are and I should know, I've followed a few!" -- John Cleese in "Life of Brian" Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Michael Lucas [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 12, 2000 4:09 PM To: [EMAIL PROTECTED] Subject: Reading the kernel sources I find myself in a contract where I sit for eight hours a day and wait for something to break. It pays obscenely well, so I'm putting up with the tedium. So, if I was to sit down and start reading /usr/src/sys, where's the logical place to start? Or should I start elsehwere? Or is there no logical statring place, and I should just assimilate it all en masse? Minesweeper can only fill so many hours in a day, after all. Thanks, ==ml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: BSD XFS Port BSD VFS Rewrite
I spent an hour on the phone with SGI's lead FS scientist Dan Koren discussing the XFS situation, Margot Seltzer's LFS work, ships, sails, sealing wax... The code is not yet open. It is being "disencumbered" and retrofitted to the Linux kernel interfaces by a team of contractors and university people all under NDA. So we're on hold for the time being. Unless you want to sign an NDA and move to Iowa for a year or so. We BSDies really are going to have to come up with something in the way of a modern storage subsystem. -Original Message- From: Andrzej Bialecki [SMTP:[EMAIL PROTECTED]] Sent: Saturday, October 30, 1999 10:56 AM To: Alton, Matthew Subject: Re: BSD XFS Port BSD VFS Rewrite On Thu, 5 Aug 1999, Alton, Matthew wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon Is there anything that you might say on the progress status of this project? Thanks! Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: BSD XFS Port BSD VFS Rewrite
Do you have access to more of the code than is currently posted on SGI's web page? I am willing to sign an NDA in order to get access to all relevant source. I would like to assist in porting XFS to Linux also. I would very much like to see SGI succeed by using open source software in the commercial realm. As for licensing issues, I am purely agnostic -- I trust that any legal issues can be worked out after the fact by the proper people. -Original Message- From: Russell Cattelan [SMTP:[EMAIL PROTECTED]] Sent: Thursday, August 19, 1999 12:41 AM To: Alton, Matthew Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: BSD XFS Port BSD VFS Rewrite Glad to hear somebody is willing to dive in to XFS. Right now I am one of three people working on the XFS to linux port, so I have pretty good view of what is currently happening. When is it going to be ready? Don't hold your breath. Officially SGI has said by the end of the year, technically... whew frankly I can't even guess. I would hope within a month or so we will have the basics of a FS. There are a lot of hurtles to overcome. XFS is a very very complex file system that relies on some of the more advanced features of IRIX. The buffer cache and chunk cache (chunking buffers together to do large IO) are two examples that come to mind. SGI is rewriting the buffer cache (calling it the page cache) such that is will be able to support XFS. chunk cache... ? not sure what we are going to do with that. We have been having several discussions about the best way to "interface". IRIX uses VFS,VNODE,BEHAVIOR which is similar to the BSD's interface but of course very IRIX specific. Linux's vfs/vnode is different from either. Realizing this, a lot of our discussions have been around how to go at making a new/modify existing interface layer that might be more "universal" i.e. not irix not linux not bsd not etc specific. In reading Terry's Bill's comments seems there is a a lot of room for improvement. Initially we trying to make as few changes as possible to XFS to get an initial implementation running on linux. After we get things running we will start to analyze where the problems exist, and decide what direction in terms of interface to take at that time. I would like any constructive input people have on this matter. I have a pretty good chance of setting design direction. Be waned: SGI at the moment is committed to linux, development directions will favor that platform. They are not against other OS's being XFS'atized but SGI is in the business of selling hardware/solutions based on that hardware and linux one of the OS they have decided to use for their intel based boxes. Also as far as the GPL issue goes, get over it! I understand the issues and agree with many of the points. My suggestion lets find a way to work with the GPL (i.e. loadable kernel module / softupdates model) If somebody has a very very good argument/solution to the licensing debate let me know, I can present it to the people dealing with the lawyers. The license issue has slowed the release of the actual code more than anything else, and will not be revisited again without great pain. I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of "The Design and Implementation of the 4.4BSD Operating System" still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? -- Russell Cattelan [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: BSD-XFS Update
Pinned in the AIX-style "pinned memory" sense? Succinctly, AIX allows userland programs to tag memory pages so as to guarantee that they will not be swapped to backing store. Portions of the _KERNEL_ are paged out instead if necessary. I assume that the pinning is of the AIX sort and that it is desirable, if not necessary, for the realtime throughput guarantee policy. Nes pas? -Original Message- From: Russell Cattelan [SMTP:[EMAIL PROTECTED]] Sent: Thursday, August 19, 1999 1:01 AM To: Alton, Matthew Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: BSD-XFS Update "Alton, Matthew" wrote: SGI has released a portion of the XFS source code under the GPL: http://oss.sgi.com/projects/xfs/download/ the source file is xfs_log.tar.gz. Of greater interest at this stage are the documents in: http://oss.sgi.com/projects/xfs/design_docs/ I am currently researching methods for implementing the 64-bit syscalls stat64(), fstat64(), lseek64() etc. delineated in the SGI design doc _64 Bit File Access_ by Adam Sweeney. The 64 calls are no longer an issue as of IRIX 6.(something 2 I think) all the standard calls were converted to use 64 bit types directly. Have a better one for you to research. Find out if buffers can be pined? if not what is it going to take to fix that. The BSD-XFS port will be made available as a patch to the RELEASE FreeBSD kernels. Given the size of XFS it might be easier to make FreeBSD a patch to XFS. - major humor here. :-) :-) Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Russell Cattelan [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-fs" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: BSD XFS Port BSD VFS Rewrite
Do you have access to more of the code than is currently posted on SGI's web page? I am willing to sign an NDA in order to get access to all relevant source. I would like to assist in porting XFS to Linux also. I would very much like to see SGI succeed by using open source software in the commercial realm. As for licensing issues, I am purely agnostic -- I trust that any legal issues can be worked out after the fact by the proper people. -Original Message- From: Russell Cattelan [SMTP:catte...@thebarn.com] Sent: Thursday, August 19, 1999 12:41 AM To: Alton, Matthew Cc: 'hack...@freebsd.org'; 'f...@freebsd.org' Subject: Re: BSD XFS Port BSD VFS Rewrite Glad to hear somebody is willing to dive in to XFS. Right now I am one of three people working on the XFS to linux port, so I have pretty good view of what is currently happening. When is it going to be ready? Don't hold your breath. Officially SGI has said by the end of the year, technically... whew frankly I can't even guess. I would hope within a month or so we will have the basics of a FS. There are a lot of hurtles to overcome. XFS is a very very complex file system that relies on some of the more advanced features of IRIX. The buffer cache and chunk cache (chunking buffers together to do large IO) are two examples that come to mind. SGI is rewriting the buffer cache (calling it the page cache) such that is will be able to support XFS. chunk cache... ? not sure what we are going to do with that. We have been having several discussions about the best way to interface. IRIX uses VFS,VNODE,BEHAVIOR which is similar to the BSD's interface but of course very IRIX specific. Linux's vfs/vnode is different from either. Realizing this, a lot of our discussions have been around how to go at making a new/modify existing interface layer that might be more universal i.e. not irix not linux not bsd not etc specific. In reading Terry's Bill's comments seems there is a a lot of room for improvement. Initially we trying to make as few changes as possible to XFS to get an initial implementation running on linux. After we get things running we will start to analyze where the problems exist, and decide what direction in terms of interface to take at that time. I would like any constructive input people have on this matter. I have a pretty good chance of setting design direction. Be waned: SGI at the moment is committed to linux, development directions will favor that platform. They are not against other OS's being XFS'atized but SGI is in the business of selling hardware/solutions based on that hardware and linux one of the OS they have decided to use for their intel based boxes. Also as far as the GPL issue goes, get over it! I understand the issues and agree with many of the points. My suggestion lets find a way to work with the GPL (i.e. loadable kernel module / softupdates model) If somebody has a very very good argument/solution to the licensing debate let me know, I can present it to the people dealing with the lawyers. The license issue has slowed the release of the actual code more than anything else, and will not be revisited again without great pain. I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of The Design and Implementation of the 4.4BSD Operating System still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? -- Russell Cattelan catte...@thebarn.com 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: BSD-XFS Update
Pinned in the AIX-style pinned memory sense? Succinctly, AIX allows userland programs to tag memory pages so as to guarantee that they will not be swapped to backing store. Portions of the _KERNEL_ are paged out instead if necessary. I assume that the pinning is of the AIX sort and that it is desirable, if not necessary, for the realtime throughput guarantee policy. Nes pas? -Original Message- From: Russell Cattelan [SMTP:catte...@thebarn.com] Sent: Thursday, August 19, 1999 1:01 AM To: Alton, Matthew Cc: 'hack...@freebsd.org'; 'f...@freebsd.org' Subject: Re: BSD-XFS Update Alton, Matthew wrote: SGI has released a portion of the XFS source code under the GPL: http://oss.sgi.com/projects/xfs/download/ the source file is xfs_log.tar.gz. Of greater interest at this stage are the documents in: http://oss.sgi.com/projects/xfs/design_docs/ I am currently researching methods for implementing the 64-bit syscalls stat64(), fstat64(), lseek64() etc. delineated in the SGI design doc _64 Bit File Access_ by Adam Sweeney. The 64 calls are no longer an issue as of IRIX 6.(something 2 I think) all the standard calls were converted to use 64 bit types directly. Have a better one for you to research. Find out if buffers can be pined? if not what is it going to take to fix that. The BSD-XFS port will be made available as a patch to the RELEASE FreeBSD kernels. Given the size of XFS it might be easier to make FreeBSD a patch to XFS. - major humor here. :-) :-) Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 matthew.al...@anheuser-busch.com al...@plantnet.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- Russell Cattelan catte...@thebarn.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-fs 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: BSD XFS Port BSD VFS Rewrite
As I parse the SGI PR-speak, IRIX is to be folded into Linux over time in one massive penguin love-in. This will take place at some point after IRIX has been disencunbered of it's ATT/Univel/SCO whatever... It really is a good time to be alive. -Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED]] Sent: Friday, August 13, 1999 17:49 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: BSD XFS Port BSD VFS Rewrite This is why people should start emailing asking for a dual-license that would support incorporation into FreeBSD. good luck, the SGI crowd are very Linux-oriented. Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: BSD XFS Port BSD VFS Rewrite
As I parse the SGI PR-speak, IRIX is to be folded into Linux over time in one massive penguin love-in. This will take place at some point after IRIX has been disencunbered of it's ATT/Univel/SCO whatever... It really is a good time to be alive. -Original Message- From: Terry Lambert [mailto:tlamb...@primenet.com] Sent: Friday, August 13, 1999 17:49 To: tingu...@plains.nodak.edu Cc: howar...@wam.umd.edu; hack...@freebsd.org Subject: Re: BSD XFS Port BSD VFS Rewrite This is why people should start emailing asking for a dual-license that would support incorporation into FreeBSD. good luck, the SGI crowd are very Linux-oriented. Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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
BSD-XFS Update
SGI has released a portion of the XFS source code under the GPL: http://oss.sgi.com/projects/xfs/download/ the source file is xfs_log.tar.gz. Of greater interest at this stage are the documents in: http://oss.sgi.com/projects/xfs/design_docs/ I am currently researching methods for implementing the 64-bit syscalls stat64(), fstat64(), lseek64() etc. delineated in the SGI design doc _64 Bit File Access_ by Adam Sweeney. The BSD-XFS port will be made available as a patch to the RELEASE FreeBSD kernels. Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: BSD-XFS Update
Quite so. Thank you. I initially only looked at things like:
19 COMPAT POSIX { long lseek(int fd, long offset, int whence); }
from /usr/src/sys/kern/syscalls.master and assumed a 32-bit long int.
The easy way to deal with this is to change the calls in the XFS code.
The syscall part is mostly done.
-Original Message-
From: Julian Elischer [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, August 11, 1999 5:36 PM
To: Alton, Matthew
Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Subject: Re: BSD-XFS Update
stat, fstat, lseek are all already 64 bits in freebsd.
On Wed, 11 Aug 1999, Alton, Matthew wrote:
SGI has released a portion of the XFS source code under the GPL:
http://oss.sgi.com/projects/xfs/download/
the source file is xfs_log.tar.gz.
Of greater interest at this stage are the documents in:
http://oss.sgi.com/projects/xfs/design_docs/
I am currently researching methods for implementing the 64-bit
syscalls stat64(), fstat64(), lseek64() etc. delineated in the
SGI design doc _64 Bit File Access_ by Adam Sweeney.
The BSD-XFS port will be made available as a patch to the RELEASE
FreeBSD kernels.
Matthew Alton
Computer Services - UNIX Systems Administration
(314)632-6644 [EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
BSD-XFS Update
SGI has released a portion of the XFS source code under the GPL: http://oss.sgi.com/projects/xfs/download/ the source file is xfs_log.tar.gz. Of greater interest at this stage are the documents in: http://oss.sgi.com/projects/xfs/design_docs/ I am currently researching methods for implementing the 64-bit syscalls stat64(), fstat64(), lseek64() etc. delineated in the SGI design doc _64 Bit File Access_ by Adam Sweeney. The BSD-XFS port will be made available as a patch to the RELEASE FreeBSD kernels. Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 matthew.al...@anheuser-busch.com al...@plantnet.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: BSD-XFS Update
Quite so. Thank you. I initially only looked at things like:
19 COMPAT POSIX { long lseek(int fd, long offset, int whence); }
from /usr/src/sys/kern/syscalls.master and assumed a 32-bit long int.
The easy way to deal with this is to change the calls in the XFS code.
The syscall part is mostly done.
-Original Message-
From: Julian Elischer [SMTP:jul...@whistle.com]
Sent: Wednesday, August 11, 1999 5:36 PM
To: Alton, Matthew
Cc: 'hack...@freebsd.org'; 'f...@freebsd.org'
Subject: Re: BSD-XFS Update
stat, fstat, lseek are all already 64 bits in freebsd.
On Wed, 11 Aug 1999, Alton, Matthew wrote:
SGI has released a portion of the XFS source code under the GPL:
http://oss.sgi.com/projects/xfs/download/
the source file is xfs_log.tar.gz.
Of greater interest at this stage are the documents in:
http://oss.sgi.com/projects/xfs/design_docs/
I am currently researching methods for implementing the 64-bit
syscalls stat64(), fstat64(), lseek64() etc. delineated in the
SGI design doc _64 Bit File Access_ by Adam Sweeney.
The BSD-XFS port will be made available as a patch to the RELEASE
FreeBSD kernels.
Matthew Alton
Computer Services - UNIX Systems Administration
(314)632-6644 matthew.al...@anheuser-busch.com
al...@plantnet.com
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: BSD XFS Port BSD VFS Rewrite
Thank you for this link. I assume that SGI will release the XFS code under some species of corporate community licensing scheme. The BSD/XFS will be implemented as an optional bolt-on set of kernel modules in a manner designed to avoid GPL-ifying the BSD kernel. I currently believe that this can be done so long as the modules constitute a discrete product. I will have my lawyer confirm this when the details of the SGI license become public. -Original Message- From: Chris Csanady [SMTP:ccsan...@scl.ameslab.gov] Sent: Tuesday, August 10, 1999 12:38 PM To: Alton, Matthew Cc: 'hack...@freebsd.org' Subject: Re: BSD XFS Port BSD VFS Rewrite Alton, Matthew wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of The Design and Implementation of the 4.4BSD Operating System still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: quad_t and portability
What is the approved method for getting ahold of 64 clean bits? I've been using the GNU/c9x "unsigned long long" and #ifdef-ing all over the place but this strikes me as substantially less than elegant. Once we have the bits, what is the Right Way to get them into network order? -Original Message- From: Sheldon Hearn [SMTP:[EMAIL PROTECTED]] Sent: Friday, August 06, 1999 8:34 AM To: [EMAIL PROTECTED] Subject: Re: quad_t and portability On Fri, 06 Aug 1999 15:29:25 +0200, Sheldon Hearn wrote: I want to patch wc(1) so that it uses quad_t instead of u_long. This is necessary if wc(1) is to produce sensible results for files containing more than 4GB of data. Yes yes, before you jump on my head, I meant u_quad_t. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: quad_t and portability
What is the approved method for getting ahold of 64 clean bits? I've been using the GNU/c9x unsigned long long and #ifdef-ing all over the place but this strikes me as substantially less than elegant. Once we have the bits, what is the Right Way to get them into network order? -Original Message- From: Sheldon Hearn [SMTP:sheld...@uunet.co.za] Sent: Friday, August 06, 1999 8:34 AM To: freebsd-hackers@freebsd.org Subject: Re: quad_t and portability On Fri, 06 Aug 1999 15:29:25 +0200, Sheldon Hearn wrote: I want to patch wc(1) so that it uses quad_t instead of u_long. This is necessary if wc(1) is to produce sensible results for files containing more than 4GB of data. Yes yes, before you jump on my head, I meant u_quad_t. :-) Ciao, Sheldon. 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
BSD XFS Port BSD VFS Rewrite
I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of "The Design and Implementation of the 4.4BSD Operating System" still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
BSD XFS Port BSD VFS Rewrite
I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of The Design and Implementation of the 4.4BSD Operating System still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 matthew.al...@anheuser-busch.com al...@plantnet.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: RE: DOC volunteer WAS:RE: userfs help needed.
Ach. As I read my original mail here I realize that I didn't make clear that the chief aim of developing this FS is to glean information for the FS doc. My idea is to learn by writing a toy FS and to elaborate upon the experience in the form of a FS-doc. I'll hold off until the new FS code is here. What are the perceived shortcomings of the current VFS? What suggestions are being considered for the new design? What are the principal design objectives? -Original Message- From: Matthew Dillon [SMTP:[EMAIL PROTECTED]] Sent: Friday, July 30, 1999 9:20 PM To: Alton, Matthew Cc: 'Nik Clayton'; David E. Cross; [EMAIL PROTECTED] Subject: Re: RE: DOC volunteer WAS:RE: userfs help needed. :Anyway, Mr. Dillon, once I have a development box to smack around, I :intend to start with your suggestion of implementing a filesystem :of my own concoction by returning an error for all VOP calls and :issuing a kernel printf. How visible will the new VOP code be to :me at this level? The Penguins are rewriting the bejesus out of their :VFS system to the point where all the existing FS code must be redone :to conform. Please debifurcate: :1) Any attempt from-scratch FS development should definitely wait for :the new VFS code. Start now and you'll only end up rewiting in the :Fall. :2) Hack away. All changes will be completely transparent to the FS :coder. Your code, as well as everything in 2.x and 3.x will drag :and drop right into the new model and build like the very wind. :Thanks I would go with option #2. The VFS/BIO changes are several months away at the very least. The framework hasn't even been worked out yet. The new model will not be compatible with the old, but if your stuff is in the source tree whoever winds up doing the major porting work will port it along with everything else. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: DOC volunteer WAS:RE: userfs help needed.
I'll follow these guidelines. Thank you. -Original Message- From: Nik Clayton [SMTP:n...@nothing-going-on.demon.co.uk] Sent: Friday, July 30, 1999 6:47 PM To: Alton, Matthew Cc: 'Nik Clayton'; 'Matthew Dillon'; David E. Cross; freebsd-hackers@FreeBSD.ORG; d...@freebsd.org Subject: Re: DOC volunteer WAS:RE: userfs help needed. [ cc'd to -doc, reply-to points there ] On Fri, Jul 30, 1999 at 04:09:20PM -0500, Alton, Matthew wrote: I prefer to work in flat ASCII. Perhaps the doc project can HTMLize the final product. We can, it just takes longer, that's all. It would make life simpler if you can follow the general structure, which basically consists of an overall document, containing zero or more parts, each part containing one or more chapters, each chapter containing zero or more sections, each section divided in to zero or more subsections (and so on, down to sub-sub-sub-sub-sub-sections). Each part, chapter, and section has a mandatory title. The Handbook is a good example of a document that uses parts, further divided in to chapters, and the Doc. Proj. primer is a good example of a document that dispenses with parts, and just uses chapters and sections. Generally, something like Title Abstract . . . Chapter 1: Overview . . . and then further chapters as necessary. Within the text, set off things that are 'out of band' information, like notes, tips, and important information. If you include instructions for the user to follow, please use # for the root prompt, and % for the regular user prompt. Refer to commands as 'command(n)', and assume that in the web (and PDF) version that will be generated that this will automatically turn in to a link to the manual page. The Doc. Proj. primer has a (sparse) writing style chapter that covers things like contractions, serial commas, and so on. Of course, you don't have to do any of this, it just makes it harder for whoever turns it in to DocBook (which will probably be me) to do the conversion. Once again, thanks for volunteering to do this. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu 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: RE: DOC volunteer WAS:RE: userfs help needed.
Ach. As I read my original mail here I realize that I didn't make clear that the chief aim of developing this FS is to glean information for the FS doc. My idea is to learn by writing a toy FS and to elaborate upon the experience in the form of a FS-doc. I'll hold off until the new FS code is here. What are the perceived shortcomings of the current VFS? What suggestions are being considered for the new design? What are the principal design objectives? -Original Message- From: Matthew Dillon [SMTP:dil...@apollo.backplane.com] Sent: Friday, July 30, 1999 9:20 PM To: Alton, Matthew Cc: 'Nik Clayton'; David E. Cross; freebsd-hackers@FreeBSD.ORG Subject: Re: RE: DOC volunteer WAS:RE: userfs help needed. :Anyway, Mr. Dillon, once I have a development box to smack around, I :intend to start with your suggestion of implementing a filesystem :of my own concoction by returning an error for all VOP calls and :issuing a kernel printf. How visible will the new VOP code be to :me at this level? The Penguins are rewriting the bejesus out of their :VFS system to the point where all the existing FS code must be redone :to conform. Please debifurcate: :1) Any attempt from-scratch FS development should definitely wait for :the new VFS code. Start now and you'll only end up rewiting in the :Fall. :2) Hack away. All changes will be completely transparent to the FS :coder. Your code, as well as everything in 2.x and 3.x will drag :and drop right into the new model and build like the very wind. :Thanks I would go with option #2. The VFS/BIO changes are several months away at the very least. The framework hasn't even been worked out yet. The new model will not be compatible with the old, but if your stuff is in the source tree whoever winds up doing the major porting work will port it along with everything else. -Matt Matthew Dillon dil...@backplane.com 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: DOC volunteer WAS:RE: userfs help needed.
I prefer to work in flat ASCII. Perhaps the doc project can HTMLize the final product. Currently, I'm hatching a plan to free up an AMD386/40 running FreeBSD 2.1.5 for use as a 4.x sandbox. The little thing has been faithfully and unerringly natd-ing my whole Solaris/NetBSD/Linux/ UNIXWare LAN onto the big cloud for more than 2 years. It really is emotionally difficult to pull the little box out of production. It has a personality and everything. Anyway, Mr. Dillon, once I have a development box to smack around, I intend to start with your suggestion of implementing a filesystem of my own concoction by returning an error for all VOP calls and issuing a kernel printf. How visible will the new VOP code be to me at this level? The Penguins are rewriting the bejesus out of their VFS system to the point where all the existing FS code must be redone to conform. Please debifurcate: 1) Any attempt from-scratch FS development should definitely wait for the new VFS code. Start now and you'll only end up rewiting in the Fall. 2) Hack away. All changes will be completely transparent to the FS coder. Your code, as well as everything in 2.x and 3.x will drag and drop right into the new model and build like the very wind. Thanks -Original Message- From: Nik Clayton [mailto:[EMAIL PROTECTED]] Sent: Friday, July 30, 1999 05:09 To: Alton, Matthew Cc: 'Matthew Dillon'; David E. Cross; [EMAIL PROTECTED] Subject: Re: DOC volunteer WAS:RE: userfs help needed. On Thu, Jul 29, 1999 at 10:45:51AM -0500, Alton, Matthew wrote: I ran screaming into the woods last year from trying to grok VOP_foo. The prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy FS-implementer's Guide to the new VOP_foo. All the coders have to do is answer my (at least marginally clueful) questions along the way and keep posted as to what's going on in new VM-land. I won't even pester anyone with design suggestions... very much. Solid offer, kids. Everybody wins. Give it some thought. Sounds good. Yell for any assistance you need from the Doc. Proj. In particular, the FS Implementer's Guide sounds good. What (markup) language were you planning on using? N PS: Reply-to: should probably be set to doc, but I've left that at your discretion. -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: DOC volunteer WAS:RE: userfs help needed.
I prefer to work in flat ASCII. Perhaps the doc project can HTMLize the final product. Currently, I'm hatching a plan to free up an AMD386/40 running FreeBSD 2.1.5 for use as a 4.x sandbox. The little thing has been faithfully and unerringly natd-ing my whole Solaris/NetBSD/Linux/ UNIXWare LAN onto the big cloud for more than 2 years. It really is emotionally difficult to pull the little box out of production. It has a personality and everything. Anyway, Mr. Dillon, once I have a development box to smack around, I intend to start with your suggestion of implementing a filesystem of my own concoction by returning an error for all VOP calls and issuing a kernel printf. How visible will the new VOP code be to me at this level? The Penguins are rewriting the bejesus out of their VFS system to the point where all the existing FS code must be redone to conform. Please debifurcate: 1) Any attempt from-scratch FS development should definitely wait for the new VFS code. Start now and you'll only end up rewiting in the Fall. 2) Hack away. All changes will be completely transparent to the FS coder. Your code, as well as everything in 2.x and 3.x will drag and drop right into the new model and build like the very wind. Thanks -Original Message- From: Nik Clayton [mailto:n...@nothing-going-on.demon.co.uk] Sent: Friday, July 30, 1999 05:09 To: Alton, Matthew Cc: 'Matthew Dillon'; David E. Cross; freebsd-hackers@FreeBSD.ORG Subject: Re: DOC volunteer WAS:RE: userfs help needed. On Thu, Jul 29, 1999 at 10:45:51AM -0500, Alton, Matthew wrote: I ran screaming into the woods last year from trying to grok VOP_foo. The prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy FS-implementer's Guide to the new VOP_foo. All the coders have to do is answer my (at least marginally clueful) questions along the way and keep posted as to what's going on in new VM-land. I won't even pester anyone with design suggestions... very much. Solid offer, kids. Everybody wins. Give it some thought. Sounds good. Yell for any assistance you need from the Doc. Proj. In particular, the FS Implementer's Guide sounds good. What (markup) language were you planning on using? N PS: Reply-to: should probably be set to doc, but I've left that at your discretion. -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu 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
DOC volunteer WAS:RE: userfs help needed.
I ran screaming into the woods last year from trying to grok VOP_foo. The prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy FS-implementer's Guide to the new VOP_foo. All the coders have to do is answer my (at least marginally clueful) questions along the way and keep posted as to what's going on in new VM-land. I won't even pester anyone with design suggestions... very much. Solid offer, kids. Everybody wins. Give it some thought. -Original Message- From: Matthew Dillon [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, July 28, 1999 6:31 PM To: David E. Cross Cc: [EMAIL PROTECTED] Subject: Re: userfs help needed. :I am wading through the portalfs and nullfs source, but I am desperately :lost. I would love to be able to find out who would be willing to help out :with questions. I feel I would be spamming far too many people by just sending :to -hackers. Some of the topics I am curious about are general fs-style :questions, what the various vop/vfs calls do. Also I would like to know how :to setup a shared memory segment between kernel and user space (as matt :dillon suggested). Finally I would like to know how the buffer-cache interacts :with the filesystem layer. : :Thanks :-- :David Cross | email: [EMAIL PROTECTED] :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Ouch. I don't think anyone understands the VOP stuff completely. It's a big mess -- which is why it's going to be rewritten later this year. Your best bet is to study the implementation of the UFS/FFS filesystem. It may also help to study a more recent filesystem such as coda. Specifically, ufs/ufs/ufs_vfsops.c ufs/ufs/ufs_vnops.c ufs/ffs/ffs_vfsops.c ufs/ffs/ffs_vnops.c coda/coda_vfsops.c coda/coda_vnops.c What I recommend is that you implement a skeleton that essentially returns an error for all the call entries and does a kernel printf(), and then implement the routines one at a time. The various VOP calls have different locking requirements and resource freeing requirements. The most difficult resource to deal with in the entire subsystem is the struct componentname structure used for lookup and related ops - all related to namei. That is, the code that deals with path elements. Generally speaking the VOP code is required to free a pathname component before returning, but not in all cases. It's a really odd set of rules and I'd have to review them myself to be able to explain them. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
DOC volunteer WAS:RE: userfs help needed.
I ran screaming into the woods last year from trying to grok VOP_foo. The prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy FS-implementer's Guide to the new VOP_foo. All the coders have to do is answer my (at least marginally clueful) questions along the way and keep posted as to what's going on in new VM-land. I won't even pester anyone with design suggestions... very much. Solid offer, kids. Everybody wins. Give it some thought. -Original Message- From: Matthew Dillon [SMTP:dil...@apollo.backplane.com] Sent: Wednesday, July 28, 1999 6:31 PM To: David E. Cross Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: userfs help needed. :I am wading through the portalfs and nullfs source, but I am desperately :lost. I would love to be able to find out who would be willing to help out :with questions. I feel I would be spamming far too many people by just sending :to -hackers. Some of the topics I am curious about are general fs-style :questions, what the various vop/vfs calls do. Also I would like to know how :to setup a shared memory segment between kernel and user space (as matt :dillon suggested). Finally I would like to know how the buffer-cache interacts :with the filesystem layer. : :Thanks :-- :David Cross | email: cro...@cs.rpi.edu :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Ouch. I don't think anyone understands the VOP stuff completely. It's a big mess -- which is why it's going to be rewritten later this year. Your best bet is to study the implementation of the UFS/FFS filesystem. It may also help to study a more recent filesystem such as coda. Specifically, ufs/ufs/ufs_vfsops.c ufs/ufs/ufs_vnops.c ufs/ffs/ffs_vfsops.c ufs/ffs/ffs_vnops.c coda/coda_vfsops.c coda/coda_vnops.c What I recommend is that you implement a skeleton that essentially returns an error for all the call entries and does a kernel printf(), and then implement the routines one at a time. The various VOP calls have different locking requirements and resource freeing requirements. The most difficult resource to deal with in the entire subsystem is the struct componentname structure used for lookup and related ops - all related to namei. That is, the code that deals with path elements. Generally speaking the VOP code is required to free a pathname component before returning, but not in all cases. It's a really odd set of rules and I'd have to review them myself to be able to explain them. -Matt Matthew Dillon dil...@backplane.com 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: implementing a fs on a raw partition
If someone in the FS dept. would draw up a broad outline for FS implementation I hereby volunteer to flesh it out thoroughly and donate the end-product docs to the FreeBSD project. I am a professional UNIX (AIX/SOLARIS) programmer and fairly clueful kernel source peruser and tweaker, fully capable of producing professional quality technical documentation. I propose the following iterative process: 1) FS guru draws up broad scheme. 2) I flesh it out with resort to trial and error research, trying very hard to figure everything out for myself but ask precisely worded usually Y/N questions when I get good and stumped. 3) I submit draft for inspection by FS people, receive feedback. 4) I repair draft goto (2) Please refer only to 3.x 4.x methodology in the broad scheme. We'll make this a baseline and allow any deprecated stuff to properly atrophy into mummy dust. The purpose of this exercise is to produce a definitive procedure for coding new filesystems for use in the FreeBSD kernel. Benefits include speed of porting of 'foreign' FSes and feedback to the core group on implementation issues. Please CC [EMAIL PROTECTED] and [EMAIL PROTECTED] in replies. The wife is 10 days overdue to deliver a baby and I'll (God, hopefully) be on vacation all next week and in sleep deprivation hallucinatory mode. -Original Message- From: Marc Tardif [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, July 07, 1999 9:22 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: implementing a fs on a raw partition As I reading on filesystem algorithms and principles [bach 86 and mckusick 96], I am tempted to try my hand on a free partition. From my understanding, I should be using the partition as a character device for raw i/o in order to avoid the current filesystem overhead (/dev/rwd0s3). From that point, I've been using the code from /usr/src/sys/msdosfs in order to get something going at first... but this has shown to be an exhausting task. I keep running into dependencies and such which make it seem impossible to implement. Perhaps I have taken a wrong turn at Albuquerque, so I'd appreciate if anyone could give a hint to get me up and running. Thanks in advance, Marc [bach 86] The Design of the UNIX Operating System, Maurice J. Bach [mckusick 96] The Design and Implementation of the 4.4BSD Operating System, Marshall McKusick, Keith Bostic, Michael J. Karels, John S. Quarterman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-fs" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: implementing a fs on a raw partition
If someone in the FS dept. would draw up a broad outline for FS implementation I hereby volunteer to flesh it out thoroughly and donate the end-product docs to the FreeBSD project. I am a professional UNIX (AIX/SOLARIS) programmer and fairly clueful kernel source peruser and tweaker, fully capable of producing professional quality technical documentation. I propose the following iterative process: 1) FS guru draws up broad scheme. 2) I flesh it out with resort to trial and error research, trying very hard to figure everything out for myself but ask precisely worded usually Y/N questions when I get good and stumped. 3) I submit draft for inspection by FS people, receive feedback. 4) I repair draft goto (2) Please refer only to 3.x 4.x methodology in the broad scheme. We'll make this a baseline and allow any deprecated stuff to properly atrophy into mummy dust. The purpose of this exercise is to produce a definitive procedure for coding new filesystems for use in the FreeBSD kernel. Benefits include speed of porting of 'foreign' FSes and feedback to the core group on implementation issues. Please CC al...@plantnet.com and al...@van.accessus.net in replies. The wife is 10 days overdue to deliver a baby and I'll (God, hopefully) be on vacation all next week and in sleep deprivation hallucinatory mode. -Original Message- From: Marc Tardif [SMTP:intm...@cam.org] Sent: Wednesday, July 07, 1999 9:22 PM To: freebsd-hackers@freebsd.org Cc: freebsd...@freebsd.org Subject: implementing a fs on a raw partition As I reading on filesystem algorithms and principles [bach 86 and mckusick 96], I am tempted to try my hand on a free partition. From my understanding, I should be using the partition as a character device for raw i/o in order to avoid the current filesystem overhead (/dev/rwd0s3). From that point, I've been using the code from /usr/src/sys/msdosfs in order to get something going at first... but this has shown to be an exhausting task. I keep running into dependencies and such which make it seem impossible to implement. Perhaps I have taken a wrong turn at Albuquerque, so I'd appreciate if anyone could give a hint to get me up and running. Thanks in advance, Marc [bach 86] The Design of the UNIX Operating System, Maurice J. Bach [mckusick 96] The Design and Implementation of the 4.4BSD Operating System, Marshall McKusick, Keith Bostic, Michael J. Karels, John S. Quarterman To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-fs 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: linux and freebsd kernels conceptually different?
Yes, quite. -Original Message- From: Christoph Kukulies [SMTP:k...@gilberto.physik.rwth-aachen.de] Sent: Monday, June 07, 1999 10:59 AM To: hack...@freebsd.org Subject: linux and freebsd kernels conceptually different? Could one say that Linux vs. FreeBSD kernels are conceptually different what task scheduling, queueing, interrupt handling, driver architecture, buffer caching, vm etc. is concerned? -- Chris Christoph P. U. Kukulies k...@gil.physik.rwth-aachen.de 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: serial ports
Well, the serial devices are not typically used for TCP traffic, but you should look at ioctl(3), read(3), write(3), socket(3), bind(3), listen(3), send(3), recv(3) for starters. The tty devices are treated as files. Remember, in UNIX everything is a file unless it isn't. The ethernet cards, which cropped up after the 70s and which are not treated as files, are accustomed to TCP traffic. You might want to have a look at these instead. -Original Message- From: Keith Anderson [SMTP:ke...@apcs.com.au] Sent: Wednesday, May 26, 1999 8:42 AM To: hack...@freebsd.org Subject: serial ports Dear All Could someone point me in the correct direction for help with 'c' Some examples for opening a serial port for comms. Opening tcp connections for use with mysql. I'm a programer from the 70's (DOS) and learning FBSD. Thanks Keith The box said 'Requires Windows 95, NT, or better,' so I installed FreeBSD. ** The thing I like most about Windows 98 is... ** You can download FreeBSD with it! -- E-Mail: Keith Anderson ke...@apcs.com.au Australia Power Control Systems Pty. Limited. Date: 26-May-99 Time: 23:34:29 Satelite Service 64K to 2Meg This message was sent by XFMail -- What's the similarity between an air conditioner and a computer? They both stop working when you open windows. -- 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
