re: CVS commit: src/sys/external/bsd/drm2
"Taylor R Campbell" writes: > Module Name: src > Committed By: riastradh > Date: Thu Apr 3 14:15:05 UTC 2014 > > Modified Files: > src/sys/external/bsd/drm2/dist/drm: drm_stub.c > src/sys/external/bsd/drm2/drm: drm_module.c > > Log Message: > Enable drm debug output iff boothowto has AB_DEBUG set. does this mean i can only get drm debug output when i turn on all the other debug modules? it would be nice to only have to turn on drm debug.. .mrg.
re: CVS commit: src/distrib/utils/embedded/conf
make a swap file? .mrg.
Re: CVS commit: src/sbin/fdisk
In article <20140403215619.a8f1...@cvs.netbsd.org>, Thomas Klausner wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: wiz >Date: Thu Apr 3 21:56:19 UTC 2014 > >Modified Files: > src/sbin/fdisk: fdisk.8 > >Log Message: >Update SYNOPSIS. >Christos, please check. Needs the same treatment in .It Fl s... christos
Re: CVS commit: src/sbin/fdisk
On Apr 3, 11:57pm, w...@netbsd.org (Thomas Klausner) wrote: -- Subject: Re: CVS commit: src/sbin/fdisk | On Thu, Apr 03, 2014 at 01:08:21PM -0400, Christos Zoulas wrote: | > On Apr 3, 11:09pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: | > -- Subject: Re: CVS commit: src/sbin/fdisk | > | > | Could you also update man page? Thanks. | > | > I did not like the -1 stuff anyway, I wanted to use empty strings instead. | > But now my nroff foo is not strong enough to handle: | > | > [][/[][/[][/[ | | I've tried. Let me know if you want it differently. Perfect! Thanks, christos
Re: CVS commit: src/sys/dev/raidframe
On Thu, Apr 03, 2014 at 12:13:09PM -0400, Greg Troxel wrote: > > > Or: > > 1. add the ability to pass the root name through the bootblocks/userconf > > 2. add a raidctl -A forceroot and obey that. > > > > | It seems to me that the behavior 1 (not in case 2) isn't useful, and > > | that we could make behavior 2 the default behavior, with 3 with -A yes. > > > > Yes, I think you are right. There could be an issue with having wd0a being > > the real root and then a raid component on wd0e... In that case do we want > > to make wd0e the root device because it is on the same drive? > > I don't think so. The case that matters for automatically making the > raid root is when one has a RAID1 and the bootblocks boot off of half of > it. So I think the narrow "if the boot device is a component of an > autoconfigured raid, switch the boot device to that raid" really is what > we want to do. Agreed. wd0a might have nothing to do with the raid component wd0e. I keep entirely separate bootable root filesystems for old versions and recovery. One might be i386, the other amd64 ... David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sbin/fdisk
On Thu, Apr 03, 2014 at 01:08:21PM -0400, Christos Zoulas wrote: > On Apr 3, 11:09pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > -- Subject: Re: CVS commit: src/sbin/fdisk > > | Could you also update man page? Thanks. > > I did not like the -1 stuff anyway, I wanted to use empty strings instead. > But now my nroff foo is not strong enough to handle: > > [][/[][/[][/[ I've tried. Let me know if you want it differently. Thomas
Re: CVS commit: src/sbin/fdisk
On Apr 3, 11:09pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/sbin/fdisk | Could you also update man page? Thanks. I did not like the -1 stuff anyway, I wanted to use empty strings instead. But now my nroff foo is not strong enough to handle: [][/[][/[][/[ christos
Re: CVS commit: src/sys/dev/raidframe
chris...@zoulas.com (Christos Zoulas) writes: > On Apr 3, 7:57am, m...@eterna.com.au (matthew green) wrote: > -- Subject: re: CVS commit: src/sys/dev/raidframe > > | kernel configuration changes are not solutions, so 2 and 3 are out. > | > | if we do 4, we should instead add an option to mark something as a > | 'soft root', and leave the current semantics alone. the machines i > | have that are now not going to reboot properly are both used > | remotely, so changing semantics about how they work seems like a > | bad idea. i'm pretty sure i'm not the only one who does this. > | i think i like this the best. > > Sure, we can add -A softroot. Do we want to rename the current option > to -A hardroot? If that's the consensus, I can go ahead. Why don't you just leave the current one alone, and not change the name? The names only mean what the docs say, and -A root says "and make this root, period" in the docs, which is not unsurprising for "-A root". Having "-A softroot" or "-A condroot" to mean "make this root if the existing root is a component" sounds good. This way the only people that will see new behavior are those that configure -A softroot, and I think that's a good goal. pgpdgzG97Nfh6.pgp Description: PGP signature
re: CVS commit: src/sys/dev/raidframe
On Apr 3, 8:10am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/sys/dev/raidframe | | > > 4. we can add an option to mark the raid as force root. | > | > if we do 4, we should instead add an option to mark something as a | > 'soft root', and leave the current semantics alone. the machines i | > have that are now not going to reboot properly are both used | > remotely, so changing semantics about how they work seems like a | > bad idea. i'm pretty sure i'm not the only one who does this. | > i think i like this the best. | | oh, actually. we already (can) have "soft root". by marking | something as auto-configure, and booting from it. | | what we want to change from what the past has been is to enable | the auto-configured raids to be used as root when booted from, | without them being marked -A root. we should still keep the | current -A root semantics, and then people can stop using -A | root when they don't need to force it, and just use -A yes. This has the problem of having a raid component on the same boot disk with the real root partition. christos
re: CVS commit: src/sys/dev/raidframe
On Apr 3, 7:57am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/sys/dev/raidframe | kernel configuration changes are not solutions, so 2 and 3 are out. | | if we do 4, we should instead add an option to mark something as a | 'soft root', and leave the current semantics alone. the machines i | have that are now not going to reboot properly are both used | remotely, so changing semantics about how they work seems like a | bad idea. i'm pretty sure i'm not the only one who does this. | i think i like this the best. Sure, we can add -A softroot. Do we want to rename the current option to -A hardroot? If that's the consensus, I can go ahead. christos
Re: CVS commit: src/sys/dev/raidframe
I think the most important thing is that people who have a system that boots now (and aren't doing anything super sick) should continue to have that system boot after they just replace the kernel. And we should discuss how to do this before the change is committed :-) > On Apr 2, 10:33am, g...@ir.bbn.com (Greg Troxel) wrote: > -- Subject: Re: CVS commit: src/sys/dev/raidframe > > | It seems there are 3 behaviors for root > | > | 1) don't change the root device (old behavior with -A yes) > > That does autoconfig for raid and does not deal with root at all. Right, but it is a way that some systems might be set up now. > | 2) if root is on a component, change root to the raid, otherwise don't > | change. > > This behavior did not exist before my commit. It is now only turned on with > -A root. > > | 3) force the root device to be the raid (old behavior with -A root) > > This does not exist anymore. You can currently: > > 1. boot -a > 2. make a kernel that has root on raidx so this is the real concern, that the straightforward update will make systems unbootable. > Or: > 1. add the ability to pass the root name through the bootblocks/userconf > 2. add a raidctl -A forceroot and obey that. > > | It seems to me that the behavior 1 (not in case 2) isn't useful, and > | that we could make behavior 2 the default behavior, with 3 with -A yes. > > Yes, I think you are right. There could be an issue with having wd0a being > the real root and then a raid component on wd0e... In that case do we want > to make wd0e the root device because it is on the same drive? I don't think so. The case that matters for automatically making the raid root is when one has a RAID1 and the bootblocks boot off of half of it. So I think the narrow "if the boot device is a component of an autoconfigured raid, switch the boot device to that raid" really is what we want to do. > | Is there any reason why someone would not want to use the raid for root > | when a) the system booted from a component and b) it's marked > | autoconfigurable? If anything, I think there should be a way to disable > | autoconfiguration. > > See above... There is a way to disable autoconfiguration, but there is > currently no easy way to get the old behavior? What do you think we should > do? I guess the idea that you boot from half a raid and then you use root on that half - doesn't make sense. That breaks the raid set. I think people either set things up as (typical examples) one of the following ways: boot a kernel from wd0a, which is nonraid, and have a RAID1 on wd0e/wd1e marked -A root. Here, wd0a is merely as a rescue partition and a way to load the kernel. This is what you used to have to do before RAID1 boot support, which means I think you still do have to do it on some platforms. have wd0a/wd1a be a RAID1. Boot from wd0a (or wd1a) with boot blocks that skip over the raid header, and then -A root is used to make that the root device. So the first way needs -A root to keep its current semantics. The 2nd way works with -A root, but I think it's fine to make it work with merely -A yes. pgpagpzE8AyBe.pgp Description: PGP signature
Re: CVS commit: src/sys/dev/raidframe
On Apr 2, 10:33am, g...@ir.bbn.com (Greg Troxel) wrote: -- Subject: Re: CVS commit: src/sys/dev/raidframe | It seems there are 3 behaviors for root | | 1) don't change the root device (old behavior with -A yes) That does autoconfig for raid and does not deal with root at all. | 2) if root is on a component, change root to the raid, otherwise don't | change. This behavior did not exist before my commit. It is now only turned on with -A root. | 3) force the root device to be the raid (old behavior with -A root) This does not exist anymore. You can currently: 1. boot -a 2. make a kernel that has root on raidx Or: 1. add the ability to pass the root name through the bootblocks/userconf 2. add a raidctl -A forceroot and obey that. | It seems to me that the behavior 1 (not in case 2) isn't useful, and | that we could make behavior 2 the default behavior, with 3 with -A yes. Yes, I think you are right. There could be an issue with having wd0a being the real root and then a raid component on wd0e... In that case do we want to make wd0e the root device because it is on the same drive? | Is there any reason why someone would not want to use the raid for root | when a) the system booted from a component and b) it's marked | autoconfigurable? If anything, I think there should be a way to disable | autoconfiguration. See above... There is a way to disable autoconfiguration, but there is currently no easy way to get the old behavior? What do you think we should do? christos
Re: CVS commit: src/sbin/fdisk
> Module Name: src > Committed By: christos > Date: Tue Apr 1 19:08:48 UTC 2014 > > Modified Files: > src/sbin/fdisk: fdisk.c > > Log Message: > default to something reasonable (like the interactive mode does) instead > of 0 when -1 is specified for the start or size. Could you also update man page? Thanks. --- Izumi Tsutsui
Re: CVS commit: src/distrib/utils/embedded/conf
In article <20140401184816.gq20...@snowdrop.l8s.co.uk>, David Laight wrote: >On Mon, Mar 31, 2014 at 02:18:45PM -0400, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Mon Mar 31 18:18:45 UTC 2014 >> >> Modified Files: >> src/distrib/utils/embedded/conf: x86.conf >> >> Log Message: >> remove swap; these days x86 machines don't need it. > >What about for dumps? > >Although I'm not at all sure what this particular file is for... > >From the diff it looks like it needs for TLC in order to get sane >partition offsets. The main reason I removed it is because it makes it easier to resize the ffs to the disk size, if it is the last thing on the disk, and I did not want to put swap first. But I could put swap back. /etc/rc.d/swap2 complains otherwise, and it should not :-) christos
