Re: where to start on kernel modules and NSS?
Z.C.B. wrote: Have just been looking at sitting down and looking at writing a few things, but I am a bit lost on where to start. Any suggestions on things to read in regards to NSS and writing kernel modules? These are not similar things and you don't need kernel modules for NSS. For kernel modules, you might try reading: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/articles/geom-class/kernelprog.html signature.asc Description: OpenPGP digital signature
Re: where to start on kernel modules and NSS?
On Tue, 03 Jul 2007 11:04:17 +0200 Ivan Voras [EMAIL PROTECTED] mentioned: Z.C.B. wrote: Have just been looking at sitting down and looking at writing a few things, but I am a bit lost on where to start. Any suggestions on things to read in regards to NSS and writing kernel modules? These are not similar things and you don't need kernel modules for NSS. For kernel modules, you might try reading: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/articles/geom-class/kernelprog.html Also, this document can serve a very good introduction: http://caia.swin.edu.au/reports/070622A/CAIA-TR-070622A.pdf -- Stanislav Sedov ST4096-RIPE pgp3fuiROpdZ8.pgp Description: PGP signature
Re: Where to start?
On Mon, 22 Jan 2007, [EMAIL PROTECTED] wrote: I would guess that if a way could be found to preallocate the journal space (as with mkfile(8) in sufficiently-old systems), and then record its location in a reasonably-secure location (the superblock?), it could be accessed during recovery without reference to possibly-corrupt filesystem metadata. That's the kind of approach I was thinking of. I'm sure it would be a bit of work, but it would be cool. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
Vasil Dimov wrote: Mike Silbersack wrote: Soeren Straarup wrote: [...] I'm looking for a project. [...] I'd like to see the ability to run gjournal without reformatting. If you could create a dummy file inside the filesystem, then use that area for the journal, it might be possible. I'm sure that would let a lot more people see if journalling is right for them. I am not sure about gjournal internals but what if a system crash occurs in the middle of a transaction and the fs gets corrupted and the data, necessary to fix it is in the journal, but you cannot access the journal because the file, which contains the journal, is on a corrupted fs? I think you should still be able to mount the file system read-only, even if it's not clean, so there's no problem locating the journal file. Particularly, note that the journal file should probably be located in the root of the file system, and it will have a constant size and should be allocated from the start (i.e. it never grows nor changes allocation), which means there is no way that its meta data could be damaged. On the other hand, _if_ the file system is so seriously busted that the journal file could not be located or used anymore, then it's probably a sign of physical damage, and in that case the journal wouldn't be able help you anyway. Journalling is only able to fix things after regular crashes. Disclaimer: I'm not a GEOM code expert. Someone please correct me if I'm wrong. BTW, I've just got an idea. Wouldn't it be possible to set up a journal file in a similar manner as you set up a swap file? That is, you create a sufficiently large file with dd(1) from /dev/zero, then run vnconfig(8) to create an md(4) device for it, then -- instead of running swapon(8) -- you enable journalling, using that file for the journal. I'm aware that this doesn't currently work out of the box, and there's a hen-and-egg problem during boot when fsck+mount is to be run. But I think it should be possible to make it work without too much trouble. Best regards Oliver PS: I've set reply-to to the freebsd-geom list. I think it is more appropriate than -hackers. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
On Mon, 2007-Jan-22 10:29:18 -0800, [EMAIL PROTECTED] wrote: I would guess that if a way could be found to preallocate the journal space (as with mkfile(8) in sufficiently-old systems), mkfile(8)ing a journal is easy. This would not guarantee that the journal was a contiguous block though and the journalling code would also need to be able to follow the journal contents through a block list chain defined by an inode - this is not difficult but not as easy as having a single contiguous chunk of space. and then record its location in a reasonably-secure location (the superblock?), it could be accessed during recovery without reference to possibly-corrupt filesystem metadata. The superblock is the logical location. There are a number of spare fields in the superblock that could potentially be used to contain a journal location. Files within UFS are described by an inode number so the 'location' of the journal would be an inode number. The journal code would need to verify that the given inode was internally consistent before it accessed the data. -- Peter Jeremy pgpvJW05rdUBt.pgp Description: PGP signature
Re: Where to start?
On Sat, Jan 20, 2007 at 02:48:14 -0600, Mike Silbersack wrote: On Fri, 19 Jan 2007, Soeren Straarup wrote: [...] I'm looking for a project. [...] I'd like to see the ability to run gjournal without reformatting. If you could create a dummy file inside the filesystem, then use that area for the journal, it might be possible. I'm sure that would let a lot more people see if journalling is right for them. I am not sure about gjournal internals but what if a system crash occurs in the middle of a transaction and the fs gets corrupted and the data, necessary to fix it is in the journal, but you cannot access the journal because the file, which contains the journal, is on a corrupted fs? You should better ask at the geom mailing list. -- Vasil Dimov [EMAIL PROTECTED] % Everything should be made as simple as possible, but not simpler. -- Albert Einstein pgpOW7qHZ8jqf.pgp Description: PGP signature
Re: Where to start?
I'd like to see the ability to run gjournal without reformatting. If you could create a dummy file inside the filesystem, then use that area for the journal, it might be possible ... I am not sure about gjournal internals but what if a system crash occurs in the middle of a transaction and the fs gets corrupted and the data, necessary to fix it is in the journal, but you cannot access the journal because the file, which contains the journal, is on a corrupted fs? Looking at this as purely a data-integrity problem, and knowing nothing whatsoever about gjournal internals :) I would guess that if a way could be found to preallocate the journal space (as with mkfile(8) in sufficiently-old systems), and then record its location in a reasonably-secure location (the superblock?), it could be accessed during recovery without reference to possibly-corrupt filesystem metadata. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
Quoting Soeren Straarup [EMAIL PROTECTED] (Fri, 19 Jan 2007 21:19:35 +0100): Hi I'm looking for a project. Something that would actually be used. Preferely something with kernel and geom. I have looked over the project page, but not sure where to start. How hard is your requirement that it has to be in the kernel? If it is not very strong: you could extend sade(8) to handle GEOM stuff. Bye, Alexander. -- As a math atheist, I should be excused from this. -- Calvin http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: About sade (was Re: Where to start?)
Quoting Soeren Straarup [EMAIL PROTECTED] (Sat, 20 Jan 2007 18:15:04 +0100): On Sat, Jan 20, 2007 at 01:24:44PM +0100, Alexander Leidinger wrote: Quoting Soeren Straarup [EMAIL PROTECTED] (Fri, 19 Jan 2007 21:19:35 +0100): Hi I'm looking for a project. Something that would actually be used. Preferely something with kernel and geom. I have looked over the project page, but not sure where to start. How hard is your requirement that it has to be in the kernel? If it is not very strong: you could extend sade(8) to handle GEOM stuff. How should the g* stuff be included? like extracting code from the individual g* control programs and placed in sade? I could look at doing that. I don't know that much about the possibilities the GEOM API offers. Ideally it should be able to list the existing GEOM providers and offer to add new or remove configured ones. It should also be able to newfs on GEOM providers. This may result in the renaming of the items in the initial menu (it doesn't make sense to call it fdisk when you are able to do more than the fdisk stuff), or maybe in merging the two parts. A first step would be to enhance the fdisk part and maybe rename the two items to configure and format or something better. If you are willing to have a look at this I'm willing to review the UI/usability part and suggest improvements. For the GEOM related stuff I would have to direct you to the people which already did a lot of work there (e.g. pjd/phk), but maybe I'm able to handle minor stuff there too. Bye, Alexander. -- Mulder: Scully, should we be picking out china patterns, or what? The X-Files: Small Potatoes http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
On Fri, 19 Jan 2007, Soeren Straarup wrote: Hi I'm looking for a project. Something that would actually be used. Preferely something with kernel and geom. I have looked over the project page, but not sure where to start. /Soeren I'd like to see the ability to run gjournal without reformatting. If you could create a dummy file inside the filesystem, then use that area for the journal, it might be possible. I'm sure that would let a lot more people see if journalling is right for them. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
About sade (was Re: Where to start?)
On Sat, Jan 20, 2007 at 01:24:44PM +0100, Alexander Leidinger wrote: Quoting Soeren Straarup [EMAIL PROTECTED] (Fri, 19 Jan 2007 21:19:35 +0100): Hi I'm looking for a project. Something that would actually be used. Preferely something with kernel and geom. I have looked over the project page, but not sure where to start. How hard is your requirement that it has to be in the kernel? If it is not very strong: you could extend sade(8) to handle GEOM stuff. How should the g* stuff be included? like extracting code from the individual g* control programs and placed in sade? I could look at doing that. /Soeren -- Soeren Straarup | aka OZ2DAK aka Xride FreeBSD committer | FreeBSD since 2.2.6-R If a program is not working right, then send a patch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
On 01/20/07 02:48, Mike Silbersack wrote: On Fri, 19 Jan 2007, Soeren Straarup wrote: Hi I'm looking for a project. Something that would actually be used. Preferely something with kernel and geom. I have looked over the project page, but not sure where to start. /Soeren I'd like to see the ability to run gjournal without reformatting. If you could create a dummy file inside the filesystem, then use that area for the journal, it might be possible. I'm sure that would let a lot more people see if journalling is right for them. I don't think you need to reformat. Just turning off softupdates and adding the journal on another device should work. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology An undefined problem has an infinite number of solutions. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
Eric Anderson wrote: On 01/20/07 02:48, Mike Silbersack wrote: On Fri, 19 Jan 2007, Soeren Straarup wrote: Hi I'm looking for a project. Something that would actually be used. Preferely something with kernel and geom. I have looked over the project page, but not sure where to start. /Soeren I'd like to see the ability to run gjournal without reformatting. If you could create a dummy file inside the filesystem, then use that area for the journal, it might be possible. I'm sure that would let a lot more people see if journalling is right for them. I don't think you need to reformat. Just turning off softupdates and adding the journal on another device should work. I think what Mike means is that eliminating the need of another device and just use space in the current file system, perhaps a dummy file with VV_SYSTEM. Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: Where to start?
On 01/20/07 12:37, LI Xin wrote: Eric Anderson wrote: On 01/20/07 02:48, Mike Silbersack wrote: On Fri, 19 Jan 2007, Soeren Straarup wrote: Hi I'm looking for a project. Something that would actually be used. Preferely something with kernel and geom. I have looked over the project page, but not sure where to start. /Soeren I'd like to see the ability to run gjournal without reformatting. If you could create a dummy file inside the filesystem, then use that area for the journal, it might be possible. I'm sure that would let a lot more people see if journalling is right for them. I don't think you need to reformat. Just turning off softupdates and adding the journal on another device should work. I think what Mike means is that eliminating the need of another device and just use space in the current file system, perhaps a dummy file with VV_SYSTEM. Cheers, Yea, that would be interesting, indeed. If we only had shrinkfs for UFS2. :) Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology An undefined problem has an infinite number of solutions. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
On 01/19/07 14:19, Soeren Straarup wrote: Hi I'm looking for a project. Something that would actually be used. Preferely something with kernel and geom. I have looked over the project page, but not sure where to start. /Soeren You can try the freebsd-geom@ list - there's always people there with ideas. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology An undefined problem has an infinite number of solutions. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start for someone new to kernel coding
On Wed, Oct 06, 2004 at 09:33:50PM +0200, John Oxley wrote: I want to extend the disk quota system: - Implement a user space daemon to control it. - Pass control from the kernel to the user space daemon. [skipped] Is this at all possible, and if so, where should I start looking for coding with the kernel. Quota checks are implemented in chk*() functions from the sys/ufs/ufs/ufs_quota.c file. If you want to implement your idea as a replacement of existing QUOTA, then you need to modify this file and probably some others. It is also possible to change addresses of these functions, but this is a hack. Another way is using stackable VFS or MAC framework. In these approaches your module will have control before actual FS code is called. And a module can decide what to do: use already loaded own quota policy in the kernel or send a message to a process, which will decide what to do and send a reply back to your module. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
