Re: about GEOM 'geoms' chain question
In message [EMAIL PROTECTED], kai ouyang writes: If we add a partition 'da0s1h' to the box, when we excute the g_attach() function, it will call redo_rank(). My viewpoint is that the 'DEV'(da0s1h) should been added between 'Sda0' and 'Mda1'. Based my understanding on 'redo_rank', this function will change all the 'rank' of the elements on the chain, right? 'ad1', 'ad2' and their branches is irrelevant to 'ad0', why their rank must change? The rank number is used to detect loops in the topology. You may want to browse the slides from my GEOM tutorial at EuroBSDCon: http://2002.eurobsdcon.org/papers/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About DEVFS (was: Re: About GEOM...)
÷ Fri, 05.07.2002, × 06:39, Terry Lambert ÎÁÐÉÓÁÌ: Loader? ie on shutdown write a list of permissions etc into a file which the loader can slurp up next boot and shove into the kernel and be parsed. This really doesn't work very well. You end up with two sets of data. Having done something like this in practice, and had to live with the aftermath, I don't recommend it (at all). May be same mechanism as hints, like: hint.sio.0.mode=0622 why not ? Symantic very similar (there are some kernel-hardcoded values and some loader-supplied) But overall, it seems to be a move forward. agree. -- Terry -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About DEVFS (was: Re: About GEOM...)
On 5 Jul 2002, Vladimir B. Grebenschikov wrote: May be same mechanism as hints, like: hint.sio.0.mode=0622 As long as we are throwing out ideas: Aside from the fact that it's broken and at the moment wouldn't exactly DTRT, I always figured a type of mount_unionfs() with the older filesystem /dev as the upper layer and devfs as the lower layer would be the way to go. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: This is mostly because resources have been diverted away from updating working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. I disagree that DEVFS and GEOM are forwards. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Thursday, 4 July 2002 at 19:20:00 +1000, Bruce Evans wrote: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: This is mostly because resources have been diverted away from updating working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. I disagree that DEVFS and GEOM are forwards. I don't know enough about GEOM to embrace it whole-heartedly, but I think you'd be hard pressed to find anybody who disagrees that devfs is a forward. It may need some improvement, but it's so much more logical than what we had before that I really think you should explain your objections. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
Greg 'groggy' Lehey wrote: On Thursday, 4 July 2002 at 19:20:00 +1000, Bruce Evans wrote: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED]">[EMAIL PROTECTED], Bruce Evans writes: This is mostly because resources have been diverted away from updating working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. I disagree that DEVFS and GEOM are forwards. I don't know enough about GEOM to embrace it whole-heartedly, but I think you'd be hard pressed to find anybody who disagrees that devfs is a forward. It may need some improvement, but it's so much more logical than what we had before that I really think you should explain your objections. DEVFS would be an improvement for me, when upgrading boxes by adding additional hardware, so I don't have to browse the dmesg, coz I will just look up /dev (since it only shows installed hardware with DEVFS). Same for GEOM, if all that will work what's described on phk's website about GEOM, then it's definitely an improvement too. I'm especially seeing forward for Copy-on-Write and encryption functionality. -mg
Re: About GEOM...
On Wed, 3 Jul 2002, Terry Lambert wrote: Bruce Evans wrote: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. Are you kidding?!? That's why it *should* be standard! I don't plan to use it, so making it standard would just get in my way. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Thu, 4 Jul 2002, Greg 'groggy' Lehey wrote: I don't know enough about GEOM to embrace it whole-heartedly, but I think you'd be hard pressed to find anybody who disagrees that devfs is a forward. It may need some improvement, but it's so much more logical than what we had before that I really think you should explain your objections. This has been discussed before. Basically, devfs creates work by moving problems around without any significant benefits. I expect control of devfs device visibility and persistence of devfs device attributes would end up mostly in a utility (devd?). But once you have such a utility, you don't need devfs (or MAKEDEV). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
In message [EMAIL PROTECTED], Mario Goebbels writes: Hi! I have some questions about it. The first one is, when I compiled GEOM into the kernel, will physical disks be controlled by it already? Or does it apply to md mounted devices yet? all disks should be GEOM'ized. And the second is, when will it be officially activated? Seems to work fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. Before 5.0 if at all possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
aren't you suppost to be honeymooning from yesterday? On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
In message [EMAIL PROTECTED], Jul ian Elischer writes: aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, 2002-07-03 at 10:59, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Jul ian Elischer writes: aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) Isn't it a bit worrying when the two overlap? :) -- Simon Dick [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mario Goebbels writes: And the second is, when will it be officially activated? Seems to work fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mario Goebbels writes: And the second is, when will it be officially activated? Seems to work fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. It will be standard because the current code does not support at least two of our platforms for normal disk sizes and none of our platforms for big disk sizes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. It will be standard because the current code does not support at least two of our platforms for normal disk sizes and none of our platforms for big disk sizes. This is mostly because resources have been diverted away from updating working code to write a second system. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. It will be standard because the current code does not support at least two of our platforms for normal disk sizes and none of our platforms for big disk sizes. This is mostly because resources have been diverted away from updating working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
Sick sick sick :-) On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Jul ian Elischer writes: aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
Bruce Evans wrote: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mario Goebbels writes: And the second is, when will it be officially activated? Seems to work fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. Are you kidding?!? That's why it *should* be standard! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, Jul 03, 2002 at 11:59:47AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Jul ian Elischer writes: aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) Like reading Linux source code? ducks for cover 8-) -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
