From: Blaisorblade <bla...@ya...> - 2005-03-11 19:34:38
|
On Friday 11 March 2005 20:29, bla...@ya... wrote: > Export this symbol which is now needed for a typo fix (getuid() -> > getgid()). Sorry for resending, I sent it wrong twice. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: <bla...@ya...> - 2005-03-14 11:30:46
|
Export this symbol which is now needed for a typo fix (getuid() -> getgid()). Signed-off-by: Paolo 'Blaisorblade' Giarrusso <bla...@ya...> --- linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c | 1 + 1 files changed, 1 insertion(+) diff -puN arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs arch/um/os-Linux/user_syms.c --- linux-2.6.11/arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs 2005-03-11 20:16:17.061368376 +0100 +++ linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c 2005-03-11 20:16:17.065367768 +0100 @@ -82,6 +82,7 @@ EXPORT_SYMBOL_PROTO(statfs); EXPORT_SYMBOL_PROTO(statfs64); EXPORT_SYMBOL_PROTO(getuid); +EXPORT_SYMBOL_PROTO(getgid); /* * Overrides for Emacs so that we follow Linus's tabbing style. _ |
From: <bla...@ya...> - 2005-03-14 11:51:22
|
Export this symbol which is now needed for a typo fix (getuid() -> getgid()). Signed-off-by: Paolo 'Blaisorblade' Giarrusso <bla...@ya...> --- linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c | 1 + 1 files changed, 1 insertion(+) diff -puN arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs arch/um/os-Linux/user_syms.c --- linux-2.6.11/arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs 2005-03-11 20:16:17.061368376 +0100 +++ linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c 2005-03-11 20:16:17.065367768 +0100 @@ -82,6 +82,7 @@ EXPORT_SYMBOL_PROTO(statfs); EXPORT_SYMBOL_PROTO(statfs64); EXPORT_SYMBOL_PROTO(getuid); +EXPORT_SYMBOL_PROTO(getgid); /* * Overrides for Emacs so that we follow Linus's tabbing style. _ |
From: <bla...@ya...> - 2005-03-22 17:56:40
|
Export this symbol which is not satisfied currently. The code using it has been merged, so please export this symbol. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <bla...@ya...> --- linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c | 1 + 1 files changed, 1 insertion(+) diff -puN arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs arch/um/os-Linux/user_syms.c --- linux-2.6.11/arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs 2005-03-21 15:25:39.000000000 +0100 +++ linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c 2005-03-21 15:25:39.000000000 +0100 @@ -82,6 +82,7 @@ EXPORT_SYMBOL_PROTO(statfs); EXPORT_SYMBOL_PROTO(statfs64); EXPORT_SYMBOL_PROTO(getuid); +EXPORT_SYMBOL_PROTO(getgid); /* * Overrides for Emacs so that we follow Linus's tabbing style. _ |
From: Christoph H. <hc...@in...> - 2005-03-22 18:11:59
|
On Tue, Mar 22, 2005 at 05:21:23PM +0100, bla...@ya... wrote: > > Export this symbol which is not satisfied currently. The code using it has > been merged, so please export this symbol. and it's still bogus, and you haven't replied when I mentioned it last time. |
From: Blaisorblade <bla...@ya...> - 2005-03-24 02:03:15
|
On Tuesday 22 March 2005 19:11, Christoph Hellwig wrote: > On Tue, Mar 22, 2005 at 05:21:23PM +0100, bla...@ya... wrote: > > Export this symbol which is not satisfied currently. The code using it > > has been merged, so please export this symbol. > and it's still bogus, and you haven't replied when I mentioned it last > time. In this moment I need to clean up the missing symbol. If anyone wants to remove the code using this, then he might post a patch explictly removing it, and getting it refused probably. Or at least CC uml-devel when discussing those problems. I'm not currently able to find on marc.theaimsgroup.com the mail you talk about. Can you please provide the URL to the discussion? (even on any other archive you like, obviously). That said, there are people still using that code, so it should be kept in. Also, you blocked an important patch (the one adding ->release to hw_interrupt_type) saying that *perhaps* UML should avoid having any hard irq, a la S390. You forced so the merge of a very ugly patch manually calling what should have been UML's release method (i.e. free_irq_by_irq_and_dev) in every place calling free_irq() (and in fact one was missed at first). Might you reconsider your position on that issue ? (URL of the discussion below) http://marc.theaimsgroup.com/?l=linux-kernel&w=2&r=3&s=uml+irq&q=b The patch adding the generic handling is this one: http://marc.theaimsgroup.com/?l=linux-kernel&m=109834481320519&w=2 -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Christoph H. <hc...@in...> - 2005-03-29 11:45:59
|
On Thu, Mar 24, 2005 at 03:02:28AM +0100, Blaisorblade wrote: > In this moment I need to clean up the missing symbol. If anyone wants to > remove the code using this, then he might post a patch explictly removing it, > and getting it refused probably. > > Or at least CC uml-devel when discussing those problems. I'm not currently > able to find on marc.theaimsgroup.com the mail you talk about. Can you please > provide the URL to the discussion? (even on any other archive you like, > obviously). My unaswered reply to the first submission is at http://groups-beta.google.com/group/linux.kernel/messages/de9504fe5963ccd1,0c05294c599b22b1,eab26a4ed3f8ff17?thread_id=16c905c7e28e7498&mode=thread&noheader=1&q=uml-export-getgid-for-hostfs#doc_eab26a4ed3f8ff17 (sorry, couldn't find it on marc), it's been Cc'ed to the lists you sent the patch to. > That said, there are people still using that code, so it should be kept in. But the code is totally bogus, so it should _not_ be kept. > Also, you blocked an important patch (the one adding ->release to > hw_interrupt_type) saying that *perhaps* UML should avoid having any hard > irq, a la S390. You forced so the merge of a very ugly patch manually calling > what should have been UML's release method (i.e. free_irq_by_irq_and_dev) in > every place calling free_irq() (and in fact one was missed at first). Might > you reconsider your position on that issue ? (URL of the discussion below) > > http://marc.theaimsgroup.com/?l=linux-kernel&w=2&r=3&s=uml+irq&q=b > > The patch adding the generic handling is this one: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=109834481320519&w=2 I still think it's a really bad idea. But I'm not the irq code maintainer, it could very well be Ingo overrides me. |
From: Blaisorblade <bla...@ya...> - 2005-03-30 19:06:44
|
On Tuesday 29 March 2005 13:45, Christoph Hellwig wrote: > On Thu, Mar 24, 2005 at 03:02:28AM +0100, Blaisorblade wrote: > > In this moment I need to clean up the missing symbol. If anyone wants to > > remove the code using this, then he might post a patch explictly removing > > it, and getting it refused probably. > > > > Or at least CC uml-devel when discussing those problems. I'm not > > currently able to find on marc.theaimsgroup.com the mail you talk about. > > Can you please provide the URL to the discussion? (even on any other > > archive you like, obviously). > > My unaswered reply to the first submission is at > > http://groups-beta.google.com/group/linux.kernel/messages/de9504fe5963ccd1, >0c05294c599b22b1,eab26a4ed3f8ff17?thread_id=16c905c7e28e7498&mode=thread&noh >eader=1&q=uml-export-getgid-for-hostfs#doc_eab26a4ed3f8ff17 > > (sorry, couldn't find it on marc), it's been Cc'ed to the lists you sent > the patch to. Sorry, I wasn't clear... I read *that* answer, but it says "as mentioned in the discussion about ROOT_DEV", and I couldn't find it. Also, I'd like to know whether there's a correct way to implement this (using something different than root_dev, for instance the init[1] root directory mount device). I understand that with the possibility for multiple mounts the "root device" is more difficult to know (and maybe this is the reason for which ROOT_DEV is bogus, is this?), but at least a check on the param "rootfstype=hostfs" could be done. > > That said, there are people still using that code, so it should be kept > > in. > > But the code is totally bogus, so it should _not_ be kept. > > > Also, you blocked an important patch (the one adding ->release to > > hw_interrupt_type) saying that *perhaps* UML should avoid having any hard > > irq, a la S390. You forced so the merge of a very ugly patch manually > > calling what should have been UML's release method (i.e. > > free_irq_by_irq_and_dev) in every place calling free_irq() (and in fact > > one was missed at first). Might you reconsider your position on that > > issue ? (URL of the discussion below) > > > > http://marc.theaimsgroup.com/?l=linux-kernel&w=2&r=3&s=uml+irq&q=b > > > > The patch adding the generic handling is this one: > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=109834481320519&w=2 > > I still think it's a really bad idea. Hmm, you don't seem very talkative, sorry. You can explain why doing that hurts anyhow. You only said very vaguely "there is another way to do this" (still to prove). And actually this caused the merge, in place of that clean patch, of the current hack, described above in the quoted text. > But I'm not the irq code maintainer, > it could very well be Ingo overrides me. Ok, this is nice. I'll repost the (updated) patch CC'ing Ingo Molnar (unless there's another Ingo). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Christoph H. <hc...@in...> - 2005-03-31 14:40:34
|
On Wed, Mar 30, 2005 at 08:05:26PM +0200, Blaisorblade wrote: > > My unaswered reply to the first submission is at > > > > http://groups-beta.google.com/group/linux.kernel/messages/de9504fe5963ccd1, > >0c05294c599b22b1,eab26a4ed3f8ff17?thread_id=16c905c7e28e7498&mode=thread&noh > >eader=1&q=uml-export-getgid-for-hostfs#doc_eab26a4ed3f8ff17 > > > > (sorry, couldn't find it on marc), it's been Cc'ed to the lists you sent > > the patch to. > Sorry, I wasn't clear... I read *that* answer, but it says "as mentioned in > the discussion about ROOT_DEV", and I couldn't find it. That'd be: http://marc.theaimsgroup.com/?l=linux-fsdevel&m=110664428918937&w=2 > Also, I'd like to know whether there's a correct way to implement this (using > something different than root_dev, for instance the init[1] root directory > mount device). I understand that with the possibility for multiple mounts the > "root device" is more difficult to know (and maybe this is the reason for > which ROOT_DEV is bogus, is this?), but at least a check on the param > "rootfstype=hostfs" could be done. personally I think it's a bad misfeature by itself. If you absolutely want it make it a mount option so it's explicit at least. And yes, the only place where ROOT_DEV makes sense is in the early boot process where the first filesystem in the first namespace is mounted, that's why I want to get rid of the export to modules for it. > Ok, this is nice. I'll repost the (updated) patch CC'ing Ingo Molnar (unless > there's another Ingo). Yupp, mingo |
From: Rob L. <ro...@la...> - 2005-04-01 05:28:45
|
On Thursday 31 March 2005 09:40 am, Christoph Hellwig wrote: > > Sorry, I wasn't clear... I read *that* answer, but it says "as mentioned > > in the discussion about ROOT_DEV", and I couldn't find it. > > That'd be: > > http://marc.theaimsgroup.com/?l=linux-fsdevel&m=110664428918937&w=2 As the only user who seems to be crazy enough to regularly run UML with a hostfs root (ala "./linux rootfstype=hostfs rw init=/bin/sh"), I'd just like to say that I'm fairly certain I'm _not_ using ROOT_DEV special casing (my root files actually do belong to root, I'm just borrowing the parent's filesystem to avoid the trouble of setting up a whole filesystem under loopback.) And actually, the ROOT_DEV hack wouldn't help me, because my project is using a dirty trick where I make a loopback mounted ext2 image (which could easily be ramfs or tmpfs if my project didn't need 500 megs of scratch space), --bind mount all the directories from the parent I need into it, and chroot into it. (Thus I have the parent's binaries and libraries, but the rest is writeable space I can mknod and chown and such in.) This is done with a trivial shell script, the guts of which are: ----------------------- for i in /* do i="${i:1}" if [ "$i" != "lost+found" ] then if [ -h "$i" ] then # Copy symlinks ln -s `readlink "$i"` "$i" elif [ -d "/$i" ] then # Bind mount directories mkdir "$i" && mount -n -o bind "/$i" "$i" fi fi if [ $? -ne 0 ]; then exit 1; fi done # Don't use system /tmp, use a tmp in workspace.img. umount tmp mount -n -t devpts /dev/pts dev/pts -------------------- With that, the hostfs might as well be read-only. And as you can see, the above will very much NOT work with anything that cares about ROOT_DEV, since ROOT_DEV gets chrooted away fairly quickly... > > Also, I'd like to know whether there's a correct way to implement this > > (using something different than root_dev, for instance the init[1] root > > directory mount device). I understand that with the possibility for > > multiple mounts the "root device" is more difficult to know (and maybe > > this is the reason for which ROOT_DEV is bogus, is this?), but at least a > > check on the param "rootfstype=hostfs" could be done. > > personally I think it's a bad misfeature by itself. If you absolutely > want it make it a mount option so it's explicit at least. If it's going to have it at all, then yes it should be done the way. Lots of filesystems have something close to this (The affs uid= and gid= options aren't that far off, for example.) I'd like to point out that hostfs's rootflags= parsing needs an update. Right now, it sets the path to the parent directory hostfs is to mount from, period. (If omitted, the default is "rootflags=/".) Appending something like ,rw gets treated as part of the path, so right now turning this feature on would require a remount after UML came up. Unless it's ALWAYS the default that a hostfs mount turns files belonging to the user running UML into files belonging to root. It's possible that this is really the intended behavior, by the way. Whether the mount point is ROOT_DEV or not is probably irrelevant. Then again, I haven't personally needed this behavior yet. Mounting hostfs when UML is run by a non-root user means I can't mknod or chown, no matter what ownership or permissions the directory I'm in has. And THAT is something that means I have to supplement hostfs with a loopback mount to get real writeable space in which I can get anything major done. Making files look like they belong to root is a purely cosmetic change under those circumstances. > And yes, the only place where ROOT_DEV makes sense is in the early boot > process where the first filesystem in the first namespace is mounted, > that's why I want to get rid of the export to modules for it. > > > Ok, this is nice. I'll repost the (updated) patch CC'ing Ingo Molnar > > (unless there's another Ingo). > > Yupp, mingo Is anyone, anywhere, actually USING this? I'm using hostfs root fairly extensively and _not_ using the funky ownership rewriting feature. Is this something people thought might be needed, or is somewhere somewhere actually inconvenienced by the lack? Rob |