From: Jeff D. <jd...@ka...> - 2001-10-06 12:37:16
|
ad...@do... said: > Also, there is the concept of uml init calls. So, what's the value of having this in addition to the normal __init calls? Jeff |
From: Jeff D. <jd...@ka...> - 2001-10-06 15:56:47
|
ad...@do... said: > I have patched uml to handle its command line, in a similiar manner to > the way the main-stream kernel does it. Cool. This is clean. It might also eliminate some compilation warnings. > If there is no help text, use the empty string, *NOT* NULL. I'd like to blow up the build if there's no help text. Is there an easy way to do that? You seem to have gone overboard with __uml_init unless you have plans for that which aren't evident from the patch. You implement no semantics for it whatsoever besides sticking __uml_init stuff in its own section. If you intend just that the memory be reclaimed, then those are the same semantics as __init, and we might as well just use that. Jeff |
From: Adam H. <ad...@do...> - 2001-10-06 18:40:58
|
On Sat, 6 Oct 2001, Jeff Dike wrote: > ad...@do... said: > > I have patched uml to handle its command line, in a similiar manner to > > the way the main-stream kernel does it. > > Cool. This is clean. It might also eliminate some compilation warnings. It didn't. I'm working on another patch to eliminate the warnings(all but 2, which I may defer to the list on). > > If there is no help text, use the empty string, *NOT* NULL. > > I'd like to blow up the build if there's no help text. Is there an easy way > to do that? What if the help were set to "foo"(literally). Should the build blow up in that case? > You seem to have gone overboard with __uml_init unless you have plans for > that which aren't evident from the patch. You implement no semantics for > it whatsoever besides sticking __uml_init stuff in its own section. > > If you intend just that the memory be reclaimed, then those are the same > semantics as __init, and we might as well just use that. When I first started developing it, I wasn't fully aware of the end result. I agree, and I should store the data and code into the standard init sections. |
From: Jeff D. <jd...@ka...> - 2001-10-07 00:37:18
|
ad...@do... said: > What if the help were set to "foo"(literally). Should the build blow > up in that case? If someone is so determined not to document a switch that they will stick "foo" in there, then they will stick in "bar" if we outlaw "foo". So, just special-case the empty string and make it blow up the build. Jeff |
From: Adam H. <ad...@do...> - 2001-10-07 03:38:26
|
On Sat, 6 Oct 2001, Jeff Dike wrote: > ad...@do... said: > > What if the help were set to "foo"(literally). Should the build blow > > up in that case? > > If someone is so determined not to document a switch that they will stick > "foo" in there, then they will stick in "bar" if we outlaw "foo". So, just > special-case the empty string and make it blow up the build. I could make the macro definition variable, but when it expands the macro, it would make invalid code. Of course, someone could just put in the empty string in that case. If you put NULL there, the compile breaks. I don't know how to test for the empty string, except doing it during link, with some other script. |
From: Adam H. <ad...@do...> - 2001-10-06 18:38:52
|
On Sat, 6 Oct 2001, Jeff Dike wrote: > ad...@do... said: > > Also, there is the concept of uml init calls. > > So, what's the value of having this in addition to the normal __init calls? As I said previously, uml init calls happen before we chain to the kernel. They are used to read user space, and setup certain values that we may need to wrap the kernel with. kk |