Syslinux - Jun 2009 - [Syslinux-GSoC]Successed in converting the cache code to C

hi there,

The cache code of C version worked well(at least for extlinux, and this is
what I'm doing). you can go and check it on my git
web<http://git.zytor.com/?p=users/liu/gsoc09_liu.git;a=shortlog;h=refs/heads/extlinux>
.

Besides this, I got some new trouble:
the first is about git. When I cloned all the syslinux code from the
syslinux.git, then I'll do my work on it. And after adding some new stuff, I
should push it on my git web. So, there is the problem. I need do the
following to push my own work :
git remote rm origin       /* rm it first */
git remote add origin ssh://..../gsoc_liu.git
then I can push my stuff by
git push origin (branch)

After this (in fact, after the 'git rmote rm origin'), I can't
update the
code by 'git pull' any more. While, in fact, the syslinux code is
changed
every day, and in some case I have to update it. so how can I do it with git
push stuff to my git web while git pull stuff from syslinux git web
synchronously and easily?

the second is about printf. It doesn't work well in the formart string.
I'll
debug it now but I don't think I can fix it.


After this I will change the load_config part to C, then testing it with
extlinux (Just change the load_config first, after that, I will try to merge
the EXT fs drive written for user space into core). so, this is the current
plan.

best wishes!

-- 
regards
liu Aleaxander

liu Aleaxander wrote:
> hi there,
> 
> The cache code of C version worked well(at least for extlinux, and this
> is what I'm doing). you can go and check it on my git web
>
<http://git.zytor.com/?p=users/liu/gsoc09_liu.git;a=shortlog;h=refs/heads/extlinux>.
> 
> Besides this, I got some new trouble:
> the first is about git. When I cloned all the syslinux code from the
> syslinux.git, then I'll do my work on it. And after adding some new
> stuff, I should push it on my git web. So, there is the problem. I need
> do the following to push my own work :
> git remote rm origin       /* rm it first */
> git remote add origin ssh://..../gsoc_liu.git
> then I can push my stuff by
> git push origin (branch)
> 
> After this (in fact, after the 'git rmote rm origin'), I can't
update
> the code by 'git pull' any more. While, in fact, the syslinux code
is
> changed every day, and in some case I have to update it. so how can I do
> it with git push stuff to my git web while git pull stuff from syslinux
> git web synchronously and easily?
> 
Just add the following to your .git/config file:

[branch "master"]
        remote = origin
        merge = refs/heads/master
> the second is about printf. It doesn't work well in the formart string.
> I'll debug it now but I don't think I can fix it.
I'll take a look at it.
> After this I will change the load_config part to C, then testing it with
> extlinux (Just change the load_config first, after that, I will try to
> merge the EXT fs drive written for user space into core). so, this is
> the current plan.
Great!

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Hi liu,

Looked at your code as of this morning, my time, and I'm really happy
with your progress.  You have done an absolutely great job.

Renaming open to core_open makes sense.

A few minor style nitpicks; please don't take this as anything other
than a nitpick.

Please don't put "extern" statements or function prototypes inside
.c
files.  They belong in .h files, which in turn should be put in the
include/ directory.  Use #include "foo.h" for private includes (in the
core directory), #include <bar.h> for includes loaded from elsewhere.

We probably want to separate the different filesystems out in separate
subdirectories.

In one checkin comment you say something about merging things into a
larger file.  Overall, it's better to have a lot of smaller source files
than can be understood in isolation -- large source files are a problem.
 Syslinux has too many of them as it is :)

Some of your source files have large chunks of blank lines, which is
probably excessive.

I suggest introducing the SECTOR_SHIFT and SECTOR_SIZE macros as soon as
possible; it's a lot easier to deal with than tracking down things like:

	int sec_per_block = block_size >> 9; /* 512==sector size */

later on, and it's always better to make the code document itself.

+	memset(&regs, 0, sizeof(regs) );

Preferred style is:

	memset(&regs, 0, sizeof regs);

 - No space before the final parens
 - No parens around the argument to sizeof, unless it is a type.

I suspect we should already now define a sector_t type for the sector
number.  At some point we're going to need 64-bit sector numbers, and
making that a typedef already now will make it a lot easier.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.