关于write命令,不点/yaya 请进

chenall

目前的write命令,只能写入32位的数值,也没有办法写入单字节,双字节之类的.当然也不能使用64位的.

我准备改造一下.

增加一个参数--bytes=N (N最大取值8也就是64位)

这样就可以最多一次性写入64位的数据,为了保持兼容性,默认情况下只写入32位数据(也就是上面N的默认值为4)

为了方便编程,我采用了如下代码

        addr += offset;
        arg = (char*)(unsigned int)addr;
        p = (char*)(unsigned int)&val;

        while(bytes--)
        {
                *arg++ = *p++;
        }

bytes 默认值是4,最大值是8,可以是0,为0时就不写入任何数据了.

这样子write命令就会比较灵活,根据需要可以只改动N个字节的数据.

不知这样会不会有什么问题?

chenall

ok,更新了
用xorl %eax,%eax.

不点

2011yaya2007777 发表于 2014-11-14 10:42
使用 chenall 搭建的编译环境编译 “xorw        %eax, %eax” 时没有报错！
反编译看了看，确实是编译为
...

yaya 你能否修复？不要等着 chenall 来修复，这应该算是紧急修复。挽救许多启动失败、出问题的情况。

2011yaya2007777

使用 chenall 搭建的编译环境编译 “xorw        %eax, %eax” 时没有报错！
反编译看了看，确实是编译为
xor ax, ax

不点

是的，这是我犯的一个错误。请 chenall 尽快修复。

似乎有人报告新版有问题，可能是由此而引起的。

pbatard 的修复是错的，请按照 yaya 的意见进行修复。

2011yaya2007777

2014-11-13的更新，其中：
◦fix assembler warnings　@Pete Batard
◦dosstart.S:1356: Warning: using %ax' instead of%eax’ due to `w’ suffix
◦grldrstart.S:1277: Warning: using %ax' instead of%eax’ due to `w’ suffix
似乎有问题。
这样不能确保 eax=0，下一步
movl        %eax, 0x820C        /* EAX=0, clear saved_entryno */
会出错。

应当修改
xorw        %eax, %eax
为
xorl        %eax, %eax

贝壳iT

不点 发表于 2014-8-5 16:29
因为标题里点名有我和 yaya，所以，我就假定别人通常不会进来。下面就随便谈谈一些相关的或不相关的看法， ...

很实诚，很好的为人处事道理

2011yaya2007777

支持 chenall 对 write 命令的改进。

2013-05-24 (tinybit) Fix no-emulation-mode boot code so as to load 32K of preset-menu. 不需要合并，以前已经支持 32Kb。

最近上网不便，不能及时回复处理，请谅解。大约到9月份。

不点

我印象中，yaya 自己处理过类似的问题，也就是说，不需要打这个补丁。

chenall

刚发现有一个补丁没有应用到0.4.6a上,因为这个有修改grldrstart.S,我要重新打这个补丁时出现冲突,这个需要重新打上吗?

请YAYA看一下,我对汇编不是很了解,没有办法合并.

2013-05-24 (tinybit) Fix no-emulation-mode boot code so as to load 32K of preset-menu.

相关的补丁
https://github.com/chenall/grub4 ... 204e9800998ecf8427e
https://github.com/chenall/grub4 ... 204e9800998ecf8427e

不点

因为标题里点名有我和 yaya，所以，我就假定别人通常不会进来。下面就随便谈谈一些相关的或不相关的看法，算是我们几个人之间比较私密的思想交流吧。（无忧论坛的私信系统容易被攻击，我已经屏蔽掉不用了；别人也不可能给我发 “站内短消息” 了。）

一个软件要做好，其实是蛮有难度的，需要持续不断的改进完善。譬如说神雕在 grub2 区所做的开发工作就很好，但缺乏的是持续的改进完善。一个软件不可能一步到位发展到顶峰，它总会有各种不完善，它总会遭到敌对势力的攻击（一个软件如果没有遭到攻击，那是因为它不值得攻击，对手没瞧得上这个软件）。所以软件总是需要维护的。试想，当我们在网上搜到某个软件时，如果发现软件已经有很长时间没有改动了，那我们会怎么想？通常我们会放弃这个软件，除非事先知道这个软件是经过多年锤炼的，不会再有大的更动了。

我主张，干一件事，要么就投入巨大精力把它干好，要么就干脆放弃不做了。如果不能保证时间和精力的话，恐怕其效果会很差。就是说，你可能也投入了很大的精力，但获得的成效不明显，与你所投入的精力不成正比，与你的期望值相去甚远。

启动类的开源软件，是必然要遭到攻击的。如果不攻击的话，那肯定什么地方出毛病了（比如说，有可能是你的感觉器官出毛病了，你发现不了攻击的存在；因为攻击可能以某种暗藏的、意想不到的方式而存在）。在开源操作系统（如 Linux）存在并被持续攻击的前提条件之下，启动类的开源软件肯定被攻击（除非是因没有影响力等原因而不值得攻击）。【这是我的推断，这就是我的推理模式和推理习惯；我永远代表自己，不代表任何别的人。之所以强调这个，是说给那些不熟悉我的人的，或者那些故意装作不熟悉我而进来攻击我的人的。】

既然攻击是必然的，那你只能面对现实。

攻击有两种结果：一种是攻击有效，导致这个开源软件大面积瘫痪；另一种就是攻击无效，软件能够正常发展。我认为，应该面对现实，做好准备。维护者们应该权衡好，以自己所认为的恰当的方式来应对这些攻击。每个人的情况都不同。就拿我来说吧，我身体不好，又不想学习新的知识，所以，我不可能再去研究 EFI 的启动知识。所以，我只能放弃，听任其攻击；即使攻击致死也罢了，我接受这结果。这就是我的准备。维护者都应该有自己的权衡和准备，不管你是怎样权衡和准备的。

chenall

好的,我的时间也有限,

有时间就抽空处理一些小问题.

另外现在的0.4.6代码库也需要重新整理一下,我最近准备找时间重新处理一下,保持线性,目前0.4.6和0.4.5的代码库都是独立的,很不方便.

不点

write 毛病，还有很多。比如，有报告说，write 不能写 ASCII 的 NULL 字符，即 00 字符。

这些问题究竟该如何解决？我想，chenall 是可以做好的。只要有时间，只要认真做，就没有做不好的。

一切都是权衡。你就按照你的权衡，大胆尝试吧。摸着石头过河，摸错了，再拐回来，没什么不可以的。

我以前在维护 grub4dos 期间，也曾犯过很多错误，没关系，后来都纠正了。

还有一个问题是，函数的返回值，目前是 32 位的。但如果都改成 64 位的，可能更好。你看着办吧，有精力就做，没有精力就算了。比如说，checkrange 测试的值，是否应该是 64 位的呢？诸如此类，都可以考虑改进。