From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerlando Falauto Date: Fri, 10 Aug 2012 00:19:38 +0200 Subject: [U-Boot] [PATCH v3 0/6] env: handle special variables and selective env default In-Reply-To: <20120809201736.1ADF920401A@gemini.denx.de> References: <1321634955-5561-1-git-send-email-gerlando.falauto@keymile.com> <1333391204-16318-1-git-send-email-gerlando.falauto@keymile.com> <20120809201736.1ADF920401A@gemini.denx.de> Message-ID: <5024377A.8090905@keymile.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 08/09/2012 10:17 PM, Wolfgang Denk wrote: > Dear Gerlando Falauto, > > In message<1333391204-16318-1-git-send-email-gerlando.falauto@keymile.com> you wrote: >> This patchset modifies the handling of all the operations on the environment >> (set/import/default) so to unify handling of special variables. >> On top of that we implement a selective "env default". >> >> A selective "env import" would imply a user API change and should therefore >> be discussed separately. >> >> NOTE: >> The entire patchset generates an increase in code size of about 1200 bytes >> on a PowerPC target. >> As much as I would like to get rid of the set_default_vars() function in >> env_common.c, I have not found a nice way to do so. > > It appears we are stuch with this patch set. Last thing I remember > was that Marek reviewed thes epatches, and had a few comments / > requests for changes. But I cannot remember having seen any more > eplies from you. As far as I can remember (or rather, as far as I can understand reading the whole thread once again), I had managed to persuade Marek to "accept" the first 5 patches out of 6 (I guess more by means of confusion than real arguments :-) ) Then on patch 6 we got stuck on: >> [me] >> I'm not particularly fond of it either, but I'd rather do that than >> overwrite the original array. Not that it's needed afterwards by the >> caller... >> Of course the same information (variables "used") could be tracked in >> some other way (e.g. a bitmask array). > [Marek] > Well won't bitfield suffice then? [what I failed to reply] I get the impression that would probably bloat the code even more, but I haven't checked that. >> I'm not sure about the binary >> code size, but it would just make things much more complicated to >> read... and it's not like this feature (selective importing) is the core >> of the bootloader, I guess. >> >> We can of course argue whether going through the hassle of deleting a >> variable specified on the command line which is not defined in the >> default/imported env is really the right thing to do (in other words, >> whether the whole patch has the right to exist!), but that's a different >> story. That's why I enqueued it as a separate patch. > Honestly, I'm not in the position to properly argue here because I'm still > making myself familiar with the env part of uboot > Which I remember interpreting as "I will follow up later" > > Is this correct? So what is the current state? Will there be any > resubmission, or should these be applied as is, I don't remember having any more leads to follow except for the bitfield part on the last (6th) patch. But I wouldn't call my memory a reliable source of information. So please step forward if there's any suggestion. > or should they be dropped altogether? If anyone's counting hands, I'm voting against this latest action... :-) Just so I know, are we talking about the merge window closing on August 11th anyway? Thanks, Gerlando