From ed at 80386.nl Wed Oct 1 19:07:32 2008 From: ed at 80386.nl (Ed Schouten) Date: Wed Oct 1 19:07:40 2008 Subject: Expanding vops in vop_vectors during startup In-Reply-To: <20080912182722.GK1191@hoeg.nl> References: <20080912182722.GK1191@hoeg.nl> Message-ID: <20081001190728.GL16837@hoeg.nl> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20081001/68bc982c/attachment.pgp From phk at phk.freebsd.dk Wed Oct 1 20:11:21 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed Oct 1 20:11:27 2008 Subject: Expanding vops in vop_vectors during startup In-Reply-To: Your message of "Wed, 01 Oct 2008 21:07:28 +0200." <20081001190728.GL16837@hoeg.nl> Message-ID: <69186.1222890415@critter.freebsd.dk> In message <20081001190728.GL16837@hoeg.nl>, Ed Schouten writes: >The reason I'm sending this message, is because based on discussions I >had with several people on IRC we've basically got two different >opinions on this patch: > >- One group of people liked the idea of the patch. Some people even said > the patch looks good enough to be committed. > >- Another group of people also liked the idea, but thought it would make > no sense to commit it, because it's not like it's a bottleneck right > now. It should only be committed if an increase in performance is > notable. > >I did some tests with the patch set, by running tens of millions of >fstat(), fchown(), etc. calls to see how performance was affected. It >turns out on a kernel without any debugging options enabled, the >performance gain is only 1-2%, which sounds pretty valid to me. My resistance to this patch is not quite what you describe above: By factoring the vop vectors out, you remove the ability to let default vectors pick up new functionality later. I will admit that I have no knowledge of this level of generality, dating back from Heidemans Phd. dissertation, being used for anything sensible. Furthermore, if I am not mistaken, your patch increases the kernel size. Absent a plausible performance improvement, I don't see any point of your change. And that brings me to your "1-2%" measurement quoted in IRC and above. I have earlier ranted about the difference between benchmarking and random number generators, and you may have joined the project after the latest of these. Please search the mail-archives for that topic, and then use the handy ministat(1) program, to see if you have actually show any net speed benefit. Once and if you cross that threshold, I am going to raise my next objection: Benchmarking "tens of millions of fstat(), fchown(), etc. calls" and showing a 1-2% difference is patently bogus, and certainly no reason for the change you propose. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From ed at 80386.nl Wed Oct 1 20:21:10 2008 From: ed at 80386.nl (Ed Schouten) Date: Wed Oct 1 20:21:16 2008 Subject: Expanding vops in vop_vectors during startup In-Reply-To: <69186.1222890415@critter.freebsd.dk> References: <69186.1222890415@critter.freebsd.dk> Message-ID: <20081001202108.GO16837@hoeg.nl> Hello Poul-Henning, * Poul-Henning Kamp wrote: > In message <20081001190728.GL16837@hoeg.nl>, Ed Schouten writes: > > >The reason I'm sending this message, is because based on discussions I > >had with several people on IRC we've basically got two different > >opinions on this patch: > > > >- One group of people liked the idea of the patch. Some people even said > > the patch looks good enough to be committed. > > > >- Another group of people also liked the idea, but thought it would make > > no sense to commit it, because it's not like it's a bottleneck right > > now. It should only be committed if an increase in performance is > > notable. > > > >I did some tests with the patch set, by running tens of millions of > >fstat(), fchown(), etc. calls to see how performance was affected. It > >turns out on a kernel without any debugging options enabled, the > >performance gain is only 1-2%, which sounds pretty valid to me. > > > My resistance to this patch is not quite what you describe above: > > By factoring the vop vectors out, you remove the ability to let > default vectors pick up new functionality later. Could you give me an example of such functionality? You mean extending a vop_vector? That shouldn't be a problem, right? If such functionality really seems to be in conflict with this modification, it's not like we're carving things in stone here. > I will admit that I have no knowledge of this level of generality, > dating back from Heidemans Phd. dissertation, being used for anything > sensible. > > Furthermore, if I am not mistaken, your patch increases the kernel > size. Even though I admit I don't have that many file system types compiled into my kernel, binary size is 2203 bytes smaller with my patch applied. If you have a whole bunch of filesystems compiled into your kernel, these numbers might be a little different. We now need an extra SYSINIT per struct vop_vector. > Absent a plausible performance improvement, I don't see any point > of your change. > > And that brings me to your "1-2%" measurement quoted in IRC and > above. > > I have earlier ranted about the difference between benchmarking > and random number generators, and you may have joined the project > after the latest of these. > > Please search the mail-archives for that topic, and then use > the handy ministat(1) program, to see if you have actually > show any net speed benefit. > > Once and if you cross that threshold, I am going to raise my next > objection: > > Benchmarking "tens of millions of fstat(), fchown(), etc. calls" > and showing a 1-2% difference is patently bogus, and certainly > no reason for the change you propose. ministat(1) also mentions a 2% improvement with 95.0% confidence. Quite a nifty tool. Thanks for pointing me to it. About the benchmarks: the reason why I decided to test these things, was because I didn't want to measure disk I/O performance. I just wanted to see how performance was different with respect to VOP_*() calls. This means most of the cases I tested scenario's when data would already be available from cache or on pseudo-filesystems, where real disk I/O would not occur. But as I said: I am not going to commit it. End of discussion. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20081001/9b5ea7bd/attachment.pgp From gonzo at bluezbox.com Sat Oct 4 02:41:23 2008 From: gonzo at bluezbox.com (Oleksandr Tymoshenko) Date: Sat Oct 4 02:41:37 2008 Subject: Modular ata chipsets data Message-ID: <48E6D21E.8040808@bluezbox.com> Hello -arch, I was playing with p4 mips2 branch catching up with recent developments and trying to reduce kernel size for MALTA configuration. At some point I ran into ata-chipset.c. This file contains all ATA chipsets supported by FreeBSD so it was a natural candidate for axing. I hacked small proof-of-concept framework for pluggable ATA chipsets. The idea is to move all vendor-related code to separated modules (.c, not .ko), register each during compile/link-time using ATA_CHIPSET macros (utilizes DATA_SET for this purpose) and provide each chipset with kernel config option. Something like this Warner did to miibus/*phy about two years ago. So far I got only Intel vendor working (tested with Gxemul) and would like to know if it's worth to keep moving in this direction and what possible pitfalls may appear. 90Kb is not that dramatical improvement :), but it's better then nothing and code readability should be better after splitting 180K file into several, IMHO. Patch: http://people.freebsd.org/~gonzo/embedded/modular-ata.diff don't mind copyrights, they're automatically inserted by vim. -- gonzo From sos at FreeBSD.ORG Sat Oct 4 10:51:19 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Sat Oct 4 10:51:26 2008 Subject: Modular ata chipsets data In-Reply-To: <48E6D21E.8040808@bluezbox.com> References: <48E6D21E.8040808@bluezbox.com> Message-ID: <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> Hi (Please keep me CC'd as I do not normally read the list) Anyhow, what I would like to see is that the chipset support get moved into kernel modules, preferably auto-loadable when a given vendor is detected, but for starters that could be left out. This is the way to go for vendor supplied modules as well. I have a least 2 vendors that are looking into that way of providing support for new chipsets. For a small kernel you just load the module(s) you need and voila. I have VIP in that direction, but its not finished yet, but spiitting up things is pretty trivial for the most part, except a few gotchas here and there that will make at least autoloading a wee bit tricky. I guess the tedious part is to get all the code moved around into seperate files, how the actual compile/link/load should be done is a minor part that can be added when the seperaion is done. However, I do have most of that in place in a tree here, so thats more or less done already, I just need to pull out the right tree here and that part should be dealt with more or less. PS: in your patch you suddenly got exclusive Copyright on the Intel and AHCI code, that will get you bad karma :) -S?ren On 4Oct, 2008, at 4:17 , Oleksandr Tymoshenko wrote: > Hello -arch, > > I was playing with p4 mips2 branch catching up with recent > developments > and trying to reduce kernel size for MALTA configuration. At some > point > I ran into ata-chipset.c. This file contains all ATA chipsets > supported > by FreeBSD so it was a natural candidate for axing. I hacked small > proof-of-concept framework for pluggable ATA chipsets. The idea is to > move all vendor-related code to separated modules (.c, not .ko), > register each during compile/link-time using ATA_CHIPSET macros > (utilizes DATA_SET for this purpose) and provide each chipset with > kernel config option. Something like this Warner did to miibus/*phy > about two years ago. > > So far I got only Intel vendor working (tested with Gxemul) and would > like to know if it's worth to keep moving in this direction and what > possible pitfalls may appear. > > 90Kb is not that dramatical improvement :), but it's better then > nothing > and code readability should be better after splitting 180K file into > several, IMHO. > > Patch: http://people.freebsd.org/~gonzo/embedded/modular-ata.diff > don't mind copyrights, they're automatically inserted by vim. > > -- > gonzo > -S?ren From gonzo at bluezbox.com Sat Oct 4 17:57:36 2008 From: gonzo at bluezbox.com (Oleksandr Tymoshenko) Date: Sat Oct 4 17:57:44 2008 Subject: Modular ata chipsets data In-Reply-To: <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> Message-ID: <48E7AE7D.6020709@bluezbox.com> S?ren Schmidt wrote: > Hi > > (Please keep me CC'd as I do not normally read the list) > > Anyhow, what I would like to see is that the chipset support get moved > into kernel modules, preferably auto-loadable when a given vendor is > detected, but for starters that could be left out. This is the way to go > for vendor supplied modules as well. I have a least 2 vendors that are > looking into that way of providing support for new chipsets. For a small > kernel you just load the module(s) you need and voila. > > I have VIP in that direction, but its not finished yet, but spiitting up > things is pretty trivial for the most part, except a few gotchas here > and there that will make at least autoloading a wee bit tricky. > > I guess the tedious part is to get all the code moved around into > seperate files, how the actual compile/link/load should be done is a > minor part that can be added when the seperaion is done. > However, I do have most of that in place in a tree here, so thats more > or less done already, I just need to pull out the right tree here and > that part should be dealt with more or less. Great, I'll wait for results of your work to hit svn. > PS: in your patch you suddenly got exclusive Copyright on the Intel and > AHCI code, that will get you bad karma :) Ha! I cheated by helping old ladies across the street and got some extra karma to burn:) As I told - my vim is the one to be blamed, these copyrights wasn't going to make it into svn commit anyway :) > -S?ren > > > On 4Oct, 2008, at 4:17 , Oleksandr Tymoshenko wrote: > >> Hello -arch, >> >> I was playing with p4 mips2 branch catching up with recent developments >> and trying to reduce kernel size for MALTA configuration. At some point >> I ran into ata-chipset.c. This file contains all ATA chipsets supported >> by FreeBSD so it was a natural candidate for axing. I hacked small >> proof-of-concept framework for pluggable ATA chipsets. The idea is to >> move all vendor-related code to separated modules (.c, not .ko), >> register each during compile/link-time using ATA_CHIPSET macros >> (utilizes DATA_SET for this purpose) and provide each chipset with >> kernel config option. Something like this Warner did to miibus/*phy >> about two years ago. >> >> So far I got only Intel vendor working (tested with Gxemul) and would >> like to know if it's worth to keep moving in this direction and what >> possible pitfalls may appear. >> >> 90Kb is not that dramatical improvement :), but it's better then nothing >> and code readability should be better after splitting 180K file into >> several, IMHO. >> >> Patch: http://people.freebsd.org/~gonzo/embedded/modular-ata.diff >> don't mind copyrights, they're automatically inserted by vim. >> >> -- >> gonzo >> From sos at FreeBSD.ORG Sat Oct 4 18:31:44 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Sat Oct 4 18:31:51 2008 Subject: Modular ata chipsets data In-Reply-To: <48E7AE7D.6020709@bluezbox.com> References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> <48E7AE7D.6020709@bluezbox.com> Message-ID: <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> I found the devel tree with a modulerized ATA subsystem in it, and just upgraded it to the latest greatest from -current. It can be found on http://deepcore.dk/pub/ATA as two files, ata- modules-diff that contains a diff for /sys/conf/files and ata- modules.tgz that is a replacement for /sys/dev/ata. This turns the chipset parts into a module for each vendor, and they are all compiled in as is, however they can be left out on a pr vendor basis (there are a few interdependencies though). I havn't written all the /sys/modules/ata/*/Makefiles that it would take to make it into loadable modules, but thats trivial todo. Now what I'd like to find good generic solutions to is: How to select the proper modules at config/compile time without drowning in "option ATA_BLA_BLA" in the config. How to automagically load the right modules when device probing takes place. It could be loading them all in turn and unloading those that didnt catch anything. I'm not aware of any ways to do this in the kernel, but I've been unattentive for the last many months, so it might have crept in :) Let me know how this works for you, I could very well be tempted to commit it to -current soonish as it makes some things easier to play with. PS: please keep me CC'd still, I dont read arch currently -S?ren On 4Oct, 2008, at 19:57 , Oleksandr Tymoshenko wrote: > S?ren Schmidt wrote: >> Hi >> (Please keep me CC'd as I do not normally read the list) >> Anyhow, what I would like to see is that the chipset support get >> moved into kernel modules, preferably auto-loadable when a given >> vendor is detected, but for starters that could be left out. This >> is the way to go for vendor supplied modules as well. I have a >> least 2 vendors that are looking into that way of providing support >> for new chipsets. For a small kernel you just load the module(s) >> you need and voila. >> I have VIP in that direction, but its not finished yet, but >> spiitting up things is pretty trivial for the most part, except a >> few gotchas here and there that will make at least autoloading a >> wee bit tricky. >> I guess the tedious part is to get all the code moved around into >> seperate files, how the actual compile/link/load should be done is >> a minor part that can be added when the seperaion is done. >> However, I do have most of that in place in a tree here, so thats >> more or less done already, I just need to pull out the right tree >> here and that part should be dealt with more or less. > Great, I'll wait for results of your work to hit svn. > >> PS: in your patch you suddenly got exclusive Copyright on the Intel >> and AHCI code, that will get you bad karma :) > Ha! I cheated by helping old ladies across the street and got > some extra karma to burn:) As I told - my vim is the one to be blamed, > these copyrights wasn't going to make it into svn commit anyway :) > > >> -S?ren >> On 4Oct, 2008, at 4:17 , Oleksandr Tymoshenko wrote: >>> Hello -arch, >>> >>> I was playing with p4 mips2 branch catching up with recent >>> developments >>> and trying to reduce kernel size for MALTA configuration. At some >>> point >>> I ran into ata-chipset.c. This file contains all ATA chipsets >>> supported >>> by FreeBSD so it was a natural candidate for axing. I hacked small >>> proof-of-concept framework for pluggable ATA chipsets. The idea is >>> to >>> move all vendor-related code to separated modules (.c, not .ko), >>> register each during compile/link-time using ATA_CHIPSET macros >>> (utilizes DATA_SET for this purpose) and provide each chipset with >>> kernel config option. Something like this Warner did to miibus/*phy >>> about two years ago. >>> >>> So far I got only Intel vendor working (tested with Gxemul) and >>> would >>> like to know if it's worth to keep moving in this direction and what >>> possible pitfalls may appear. >>> >>> 90Kb is not that dramatical improvement :), but it's better then >>> nothing >>> and code readability should be better after splitting 180K file into >>> several, IMHO. >>> >>> Patch: http://people.freebsd.org/~gonzo/embedded/modular-ata.diff >>> don't mind copyrights, they're automatically inserted by vim. >>> >>> -- >>> gonzo >>> > -S?ren From raj at semihalf.com Sat Oct 4 19:00:31 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Sat Oct 4 19:00:38 2008 Subject: Modular ata chipsets data In-Reply-To: <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> Message-ID: <48E7B73A.2030507@semihalf.com> S?ren Schmidt wrote: > (Please keep me CC'd as I do not normally read the list) > > Anyhow, what I would like to see is that the chipset support get moved > into kernel modules, preferably auto-loadable when a given vendor is > detected, but for starters that could be left out. This is the way to go > for vendor supplied modules as well. I have a least 2 vendors that are > looking into that way of providing support for new chipsets. For a small > kernel you just load the module(s) you need and voila. > > I have VIP in that direction, but its not finished yet, but spiitting up > things is pretty trivial for the most part, except a few gotchas here > and there that will make at least autoloading a wee bit tricky. > > I guess the tedious part is to get all the code moved around into > seperate files, how the actual compile/link/load should be done is a > minor part that can be added when the seperaion is done. > However, I do have most of that in place in a tree here, so thats more > or less done already, I just need to pull out the right tree here and > that part should be dealt with more or less. Apart from the above, have you got any plans towards refactoring the ATA driver so there is a generic ATA logic layer, clearly separate from controller specific parts and bus attachments like PCI etc.? Such a well structured approach would greatly benefit embedded systems at least, which very often have an ATA/SATA controller hanging directly on some local bus; in environments like this using our current ATA code is difficult as there needs to be some fake PCI glue provided and other hacks. Rafal From sos at FreeBSD.ORG Sat Oct 4 21:05:58 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Sat Oct 4 21:06:05 2008 Subject: Modular ata chipsets data In-Reply-To: <48E7B73A.2030507@semihalf.com> References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> <48E7B73A.2030507@semihalf.com> Message-ID: <06D9EA2E-3EB2-4F77-8AE8-CD70E6D46444@FreeBSD.ORG> On 4Oct, 2008, at 20:34 , Rafal Jaworowski wrote: > S?ren Schmidt wrote: >> (Please keep me CC'd as I do not normally read the list) >> >> Anyhow, what I would like to see is that the chipset support get >> moved >> into kernel modules, preferably auto-loadable when a given vendor is >> detected, but for starters that could be left out. This is the way >> to go >> for vendor supplied modules as well. I have a least 2 vendors that >> are >> looking into that way of providing support for new chipsets. For a >> small >> kernel you just load the module(s) you need and voila. >> >> I have VIP in that direction, but its not finished yet, but >> spiitting up >> things is pretty trivial for the most part, except a few gotchas here >> and there that will make at least autoloading a wee bit tricky. >> >> I guess the tedious part is to get all the code moved around into >> seperate files, how the actual compile/link/load should be done is a >> minor part that can be added when the seperaion is done. >> However, I do have most of that in place in a tree here, so thats >> more >> or less done already, I just need to pull out the right tree here and >> that part should be dealt with more or less. > > Apart from the above, have you got any plans towards refactoring the > ATA > driver so there is a generic ATA logic layer, clearly separate from > controller > specific parts and bus attachments like PCI etc.? Actually it is allready done that way, at least to the extent that the device in question has to look like or be able to be modelled like an ATA device. ata-isa.c ata-card.c ata-cbus.c ata-pci,c are all different bus "adaptors" that just interact with different connection methods for generic ATA devices, and presents them in a generic way to the ATA "core" below. ata-all.c ata.-queue.c ata-lowlevel,c ata-dma.c are the "core" of the ATA functionality, machinery that knows the ATA/ATAPI protocol and how to deal with it. ata-disk.c atapi-cd.c atapi-fd.c atapi-tape.c are device drivers for the different types of ATA/ATAPI devices. They know how to talk to the device, using the "core" routines from above to do transfers etc. ata-chipset.c is the collection of code that knows how to deal with specific controller related things, ie how to set a given transfer mode. ata-usb.c is somewhat special, as it lets certain USB devices show up as if they where connected to an ATA bus, utilizing ATA's flexibility to cope with just about anything that smells of ATA. > Such a well structured approach would greatly benefit embedded > systems at > least, which very often have an ATA/SATA controller hanging directly > on some > local bus; in environments like this using our current ATA code is > difficult > as there needs to be some fake PCI glue provided and other hacks. That should be very easy to setup, you just need to write an "ata- yourbus.c" ala the others mentioned above to tie you given HW setup into ATA, and you're golden. Let me know a little more about you given HW, and I'll help you out doing this. BTW, I have one of these WD MyBook World lying around in pieces, any chances someone has played with getting FreeBSD onto one of those (it runs linsux from factory). Would make a nice platform to play with ARM, and I'm sure it needs ATA support to work :) -S?ren From hentschel at gmail.com Sun Oct 5 01:17:11 2008 From: hentschel at gmail.com (Thomas Hentschel) Date: Sun Oct 5 01:17:17 2008 Subject: T Message-ID: From bugmaster at FreeBSD.org Mon Oct 6 11:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 6 11:07:21 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200810061106.m96B6p2h035408@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jmg at funkthat.com Wed Oct 8 19:46:00 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Wed Oct 8 19:46:06 2008 Subject: Modular ata chipsets data In-Reply-To: <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> <48E7AE7D.6020709@bluezbox.com> <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> Message-ID: <20081008193440.GR783@funkthat.com> Sren Schmidt wrote this message on Sat, Oct 04, 2008 at 20:31 +0200: > How to select the proper modules at config/compile time without > drowning in "option ATA_BLA_BLA" in the config. Possibly use an include file that lists all of the options/devices, and then people who want to reduce it can remove it and put the respective lines in their config file directly, or turn them off through no prefix... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From jhb at freebsd.org Wed Oct 8 21:45:17 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Oct 8 21:45:23 2008 Subject: Modular ata chipsets data In-Reply-To: <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> References: <48E6D21E.8040808@bluezbox.com> <48E7AE7D.6020709@bluezbox.com> <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> Message-ID: <200810081743.45011.jhb@freebsd.org> On Saturday 04 October 2008 02:31:35 pm S?ren Schmidt wrote: > I found the devel tree with a modulerized ATA subsystem in it, and > just upgraded it to the latest greatest from -current. > It can be found on http://deepcore.dk/pub/ATA as two files, ata- > modules-diff that contains a diff for /sys/conf/files and ata- > modules.tgz that is a replacement for /sys/dev/ata. > This turns the chipset parts into a module for each vendor, and they > are all compiled in as is, however they can be left out on a pr vendor > basis (there are a few interdependencies though). > I havn't written all the /sys/modules/ata/*/Makefiles that it would > take to make it into loadable modules, but thats trivial todo. > > Now what I'd like to find good generic solutions to is: > > How to select the proper modules at config/compile time without > drowning in "option ATA_BLA_BLA" in the config. What happens with mii is that you have a choice, you can either use 'device miibus' in which case you get all of the various drivers and the infrastructure, or you can use 'device mii', 'device rlphy', etc. if you wish to take a more fine-grained approach. Similarly, there is a miibus.ko that just depends on all the sub-drivers so you can still do 'kldload miibus.ko' to load all of them. I think this is probably a fine model as it will still load everything by default, but people who care about the space savings can trim things down as desired. -- John Baldwin From sos at FreeBSD.ORG Thu Oct 9 07:44:29 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Thu Oct 9 07:44:36 2008 Subject: Modular ata chipsets data In-Reply-To: <200810081743.45011.jhb@freebsd.org> References: <48E6D21E.8040808@bluezbox.com> <48E7AE7D.6020709@bluezbox.com> <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> <200810081743.45011.jhb@freebsd.org> Message-ID: <60D39D64-FBE6-4646-AFEA-8AE8E5CE9E83@FreeBSD.ORG> On 8Oct, 2008, at 23:43 , John Baldwin wrote: > On Saturday 04 October 2008 02:31:35 pm S?ren Schmidt wrote: >> I found the devel tree with a modulerized ATA subsystem in it, and >> just upgraded it to the latest greatest from -current. >> It can be found on http://deepcore.dk/pub/ATA as two files, ata- >> modules-diff that contains a diff for /sys/conf/files and ata- >> modules.tgz that is a replacement for /sys/dev/ata. >> This turns the chipset parts into a module for each vendor, and they >> are all compiled in as is, however they can be left out on a pr >> vendor >> basis (there are a few interdependencies though). >> I havn't written all the /sys/modules/ata/*/Makefiles that it would >> take to make it into loadable modules, but thats trivial todo. >> >> Now what I'd like to find good generic solutions to is: >> >> How to select the proper modules at config/compile time without >> drowning in "option ATA_BLA_BLA" in the config. > > What happens with mii is that you have a choice, you can either use > 'device > miibus' in which case you get all of the various drivers and the > infrastructure, or you can use 'dvice mii', 'device rlphy', etc. if > you wish > to take a more fine-grained approach. Similarly, there is a > miibus.ko that > just depends on all the sub-drivers so you can still do 'kldload > miibus.ko' > to load all of them. I think this is probably a fine model as it > will still > load everything by default, but people who care about the space > savings can > trim things down as desired. Yep, I thought about that one too and I like the idea. I'm close to having it all sorted out and ready to commit, just need to polish things up a bit. I should make no functional changes just restructure chipset code into seperate files. -S?ren From avg at icyb.net.ua Thu Oct 9 12:09:12 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Oct 9 12:09:19 2008 Subject: Modular ata chipsets data In-Reply-To: <200810081743.45011.jhb@freebsd.org> References: <48E6D21E.8040808@bluezbox.com> <48E7AE7D.6020709@bluezbox.com> <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> <200810081743.45011.jhb@freebsd.org> Message-ID: <48EDF045.8030604@icyb.net.ua> on 09/10/2008 00:43 John Baldwin said the following: > What happens with mii is that you have a choice, you can either use 'device > miibus' in which case you get all of the various drivers and the > infrastructure, or you can use 'device mii', 'device rlphy', etc. if you wish > to take a more fine-grained approach. Similarly, there is a miibus.ko that > just depends on all the sub-drivers so you can still do 'kldload miibus.ko' > to load all of them. I think this is probably a fine model as it will still > load everything by default, but people who care about the space savings can > trim things down as desired. Sorry for hijacking the thread but is this documented anywhere? On RELENG_7 system I couldn't find the above info in NOTES and miibus(4), only device miibus is referred to. -- Andriy Gapon From rink at FreeBSD.org Thu Oct 9 12:39:55 2008 From: rink at FreeBSD.org (Rink Springer) Date: Thu Oct 9 12:40:02 2008 Subject: Modular ata chipsets data In-Reply-To: <48EDF045.8030604@icyb.net.ua> References: <48E6D21E.8040808@bluezbox.com> <48E7AE7D.6020709@bluezbox.com> <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> <200810081743.45011.jhb@freebsd.org> <48EDF045.8030604@icyb.net.ua> Message-ID: <20081009122251.GB89052@rink.nu> On Thu, Oct 09, 2008 at 02:51:33PM +0300, Andriy Gapon wrote: > on 09/10/2008 00:43 John Baldwin said the following: > > What happens with mii is that you have a choice, you can either use 'device > > miibus' in which case you get all of the various drivers and the > > infrastructure, or you can use 'device mii', 'device rlphy', etc. if you wish > > to take a more fine-grained approach. Similarly, there is a miibus.ko that > > just depends on all the sub-drivers so you can still do 'kldload miibus.ko' > > to load all of them. I think this is probably a fine model as it will still > > load everything by default, but people who care about the space savings can > > trim things down as desired. > > Sorry for hijacking the thread but is this documented anywhere? > On RELENG_7 system I couldn't find the above info in NOTES and > miibus(4), only device miibus is referred to. I've once tried this. Adding modules for xxxphy is easy, but I found it rather difficult to isolate which NIC needs to depend on which phy (for example, you'll want if_rl to depend on rlphy - but this isn't obvious for all NIC/PHY combinations) Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From bugmaster at FreeBSD.org Mon Oct 13 11:06:47 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 13 11:07:23 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200810131106.m9DB6kT1029370@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From bugmaster at FreeBSD.org Mon Oct 20 11:06:48 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 20 11:07:19 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200810201106.m9KB6lEW082592@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From stas at FreeBSD.org Tue Oct 21 12:22:13 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Oct 21 12:22:45 2008 Subject: RFC: making gpart default In-Reply-To: <1896.1222371977@critter.freebsd.dk> References: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> <1896.1222371977@critter.freebsd.dk> Message-ID: <20081021122544.2cf1eb1a.stas@FreeBSD.org> On Thu, 25 Sep 2008 19:46:17 +0000 "Poul-Henning Kamp" mentioned: > My proposed solution was to try to get the BSD label discontinued > and rely entirely on the native partitioning on the relevant > platforms, but that meant dealing with FAT extended partitions and > going back to libdisk and I couldn't get myself to do that. > Why abandone a well-working paritioning scheme? Granted, it has some limitations but it was the only working way of getting a decent partitioning on x86 platfrom until GPT was introduced. Stripping it out from sysinstall wouldn't be benefitable at all. Bsdlabels work great in some situations, e.g. I use them for embedded devices where bios is custom build and can successfully boot from bsdlabel-partitioned disk. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20081021/fe113ab9/attachment.pgp From scf at FreeBSD.org Wed Oct 22 01:23:33 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Wed Oct 22 01:23:40 2008 Subject: pw -V user add/del cancels out -m/-r Message-ID: Recently, someone reported an issue to me with using -V along with -m or -r when adding or deleting a user via pw, respectively. The user's home directory is not being created nor deleted. >From looking at the code, it appears that this is intended. I would expect it to look in the new /etc directory for all needed files (i.e., skel) to create the directory, but this is prevented due to the _altdir flag[1]. Would anyone know the full story behind this behavior when -V is provided? Before I change this, I would like to know all the consequences. It happened only over nine years ago; I am sure it is fresh in everyone's memory. ;) The only apparent issue I see is if the user added to the alternate /etc files has the same UID and/or GID of an existing user in the base system. If I change anything I think I should make -V apply to all /etc files (i.e., opiekeys, skel). They can always be overridden if desired. Sean 1. http://svn.freebsd.org/viewvc/base/head/usr.sbin/pw/pw_user.c?revision=44229&view=markup -- scf@FreeBSD.org From bugmaster at FreeBSD.org Mon Oct 27 11:07:09 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 27 11:07:30 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200810271107.m9RB78A3001869@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From trasz at FreeBSD.org Mon Oct 27 19:51:05 2008 From: trasz at FreeBSD.org (Edward Tomasz Napierala) Date: Mon Oct 27 19:51:12 2008 Subject: Directory rename semantics. Message-ID: <20081027193545.GA95872@pin.if.uz.zgora.pl> Let's say we have two directories, "A/" and "B/". We also have a file, "A/F". To remove that file, we need write access to "A/". To move that file to "B/", we need write access to both "A/" and "B/". Now, assume we have a directory, "A/D". To remove that directory, we need write access to "A/". To move that directory to "B/", we need write access to "A/", "B/", _and "A/D"_. I'd like to remove the last check (requirement to have write access to a directory we want to move somewhere else). Reason for this is that it doesn't seem very logical, and many systems - including SunOS, and our ZFS - behave differently. In other words, we have different semantics on UFS and ZFS. This change seems to be ok from the standards point of view - SUSv3 says the operating system MAY perform this check. Index: sys/ufs/ufs/ufs_vnops.c =================================================================== --- sys/ufs/ufs/ufs_vnops.c (revision 182813) +++ sys/ufs/ufs/ufs_vnops.c (working copy) @@ -1122,19 +1122,14 @@ * If ".." must be changed (ie the directory gets a new * parent) then the source directory must not be in the * directory hierarchy above the target, as this would - * orphan everything below the source directory. Also - * the user must have write permission in the source so - * as to be able to change "..". We must repeat the call - * to namei, as the parent directory is unlocked by the - * call to checkpath(). + * orphan everything below the source directory. We must + * repeat the call to namei, as the parent directory + * is unlocked by the call to checkpath(). */ - error = VOP_ACCESS(fvp, VWRITE, tcnp->cn_cred, tcnp->cn_thread); VOP_UNLOCK(fvp, 0); if (oldparent != dp->i_number) newparent = dp->i_number; if (doingdirectory && newparent) { - if (error) /* write access check above */ - goto bad; if (xp != NULL) vput(tvp); error = ufs_checkpath(ip, dp, tcnp->cn_cred); From das at FreeBSD.ORG Tue Oct 28 16:55:35 2008 From: das at FreeBSD.ORG (David Schultz) Date: Tue Oct 28 16:55:41 2008 Subject: Directory rename semantics. In-Reply-To: <20081027193545.GA95872@pin.if.uz.zgora.pl> References: <20081027193545.GA95872@pin.if.uz.zgora.pl> Message-ID: <20081028161855.GA45129@zim.MIT.EDU> On Mon, Oct 27, 2008, Edward Tomasz Napierala wrote: > Let's say we have two directories, "A/" and "B/". We also have a > file, "A/F". To remove that file, we need write access to "A/". > To move that file to "B/", we need write access to both "A/" and > "B/". Now, assume we have a directory, "A/D". To remove that > directory, we need write access to "A/". To move that directory > to "B/", we need write access to "A/", "B/", _and "A/D"_. > > I'd like to remove the last check (requirement to have write access > to a directory we want to move somewhere else). Reason for this > is that it doesn't seem very logical, and many systems - including > SunOS, and our ZFS - behave differently. In other words, we have > different semantics on UFS and ZFS. No comment on other operating systems or standards, but I wanted to point out that there is some logic to FreeBSD's present behavior: When you move A/D, you must be able to write to D, because you are modifying D's ".." entry to point to B instead of A. >From a practical point of view, I think either behavior is fine, but we should consider whether any security-critical applications rely on the current behavior before changing it. From avg at icyb.net.ua Wed Oct 29 12:37:40 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Oct 29 12:37:46 2008 Subject: Directory rename semantics. In-Reply-To: <20081028161855.GA45129@zim.MIT.EDU> References: <20081027193545.GA95872@pin.if.uz.zgora.pl> <20081028161855.GA45129@zim.MIT.EDU> Message-ID: <4908590C.1030904@icyb.net.ua> on 28/10/2008 18:18 David Schultz said the following: > On Mon, Oct 27, 2008, Edward Tomasz Napierala wrote: >> Let's say we have two directories, "A/" and "B/". We also have a >> file, "A/F". To remove that file, we need write access to "A/". >> To move that file to "B/", we need write access to both "A/" and >> "B/". Now, assume we have a directory, "A/D". To remove that >> directory, we need write access to "A/". To move that directory >> to "B/", we need write access to "A/", "B/", _and "A/D"_. >> >> I'd like to remove the last check (requirement to have write access >> to a directory we want to move somewhere else). Reason for this >> is that it doesn't seem very logical, and many systems - including >> SunOS, and our ZFS - behave differently. In other words, we have >> different semantics on UFS and ZFS. > > No comment on other operating systems or standards, but I wanted > to point out that there is some logic to FreeBSD's present behavior: > When you move A/D, you must be able to write to D, because you are > modifying D's ".." entry to point to B instead of A. > >>From a practical point of view, I think either behavior is fine, > but we should consider whether any security-critical applications > rely on the current behavior before changing it. Control this check by a sysctl under security.bsd? -- Andriy Gapon From cokane at FreeBSD.org Thu Oct 30 12:34:48 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Thu Oct 30 12:34:55 2008 Subject: Directory rename semantics. In-Reply-To: <20081028161855.GA45129@zim.MIT.EDU> References: <20081027193545.GA95872@pin.if.uz.zgora.pl> <20081028161855.GA45129@zim.MIT.EDU> Message-ID: <1225394214.5610.6.camel@localhost> On Tue, 2008-10-28 at 12:18 -0400, David Schultz wrote: > On Mon, Oct 27, 2008, Edward Tomasz Napierala wrote: > > Let's say we have two directories, "A/" and "B/". We also have a > > file, "A/F". To remove that file, we need write access to "A/". > > To move that file to "B/", we need write access to both "A/" and > > "B/". Now, assume we have a directory, "A/D". To remove that > > directory, we need write access to "A/". To move that directory > > to "B/", we need write access to "A/", "B/", _and "A/D"_. > > > > I'd like to remove the last check (requirement to have write access > > to a directory we want to move somewhere else). Reason for this > > is that it doesn't seem very logical, and many systems - including > > SunOS, and our ZFS - behave differently. In other words, we have > > different semantics on UFS and ZFS. > > No comment on other operating systems or standards, but I wanted > to point out that there is some logic to FreeBSD's present behavior: > When you move A/D, you must be able to write to D, because you are > modifying D's ".." entry to point to B instead of A. > > >From a practical point of view, I think either behavior is fine, > but we should consider whether any security-critical applications > rely on the current behavior before changing it. I was always mystified by the reason for this behavior until now... As for my input, I think the change sounds fine (perhaps allowing revert to old behavior via a sysctl). -- Coleman Kane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20081030/bda65b3d/attachment.pgp