On Wed, Apr 28, 2010 at 9:10 AM, Daniel Drake wrote:
> I don't have any ctypes experience, but from what I read, it looks
Just to make sure there's water before anyone jumps.
What impact would it have in our initramfs? Does it expect header
files to do its job? Does it require new modules / so f
On 28 April 2010 09:59, Martin Langhoff wrote:
> Our chvt() is in pyrex, and all it does is call ioctl() on
> /dev/console. If there's a better way to call ioctl() then we can get
> rid of pyrex in our initramfs completely.
It's not quite that simple, see e.g. pyfb/pyvt.
But yes, I believe that m
On Wed, Apr 28, 2010 at 8:32 AM, Daniel Drake wrote:
> I wouldn't have thought pyrex is necessary. I suggest using
> fnctl.ioctl() for RTC_SET_TIME, and ctypes for settimeofday().
Our chvt() is in pyrex, and all it does is call ioctl() on
/dev/console. If there's a better way to call ioctl() then
On 26 April 2010 20:21, Martin Langhoff wrote:
> I am porting some awkward patches I have against the old olpc
> initramfs to the new dracut-based, all bling initramfs.
>
> The python part is mostly done, but the fun part is that we're trying
> to set the clock (both system clock and rtc) based on
I am porting some awkward patches I have against the old olpc
initramfs to the new dracut-based, all bling initramfs.
The python part is mostly done, but the fun part is that we're trying
to set the clock (both system clock and rtc) based on network
messages.
The general approach in our initramfs
