Friday, April 27, 2007

Yay! Suspend2 Will Be Merged Into Mainline

I like to use suspend2 to do hibernation aka STD (suspend to disk) on Linux, and today, a very important step has been taken to start merge it into mainline kernel.

Rafael said

Now, I think that the hibernation should better be done completely in the
kernel, because that's just conceptually simpler, although some data exchange
with the user land may be acceptable for some optional fancy stuff. I'm also
tierd of the endless "to merge or not to merge suspend2" discussions that just
lead to nowhere. For these reasons I declare that I'm ready to cooperate with
Nigel on integrating as much of suspend2 as reasonably possible into the
existing infrastructure, under the following conditions:
- we don't remove the existing user-visible interfaces
- we work on one piece of code at a time
- we avoid code duplication, as much as possible
- we avoid using open-coded things, if possible
- if we don't agree on something, we ask someone wiser (volunteers welcome ;-))

If that's acceptable, we can start tomorrow. In the process, we can try to
separate the hibernation code paths from the s2ram ones, but that will require
a lot of knowledge about things that neither me nor Nigel, AFAICT, are very
familiar with, like writing device drivers.


And Nigel answered:
I don't want to remove user visible interfaces either (I understand that
you mean the ioctls by that?). Perhaps we can find a way to make them
still usable with a more in-kernel solution (ie some things become
noops?).

> - we work on one piece of code at a time

Sure. We should spend some time discussing and planning beforehand so we
don't waste time and effort writing and rewriting.

> - we avoid code duplication, as much as possible

No problem there.

> - we avoid using open-coded things, if possible

Regarding open-coded things, I assume you're referring to the extents. I
would argue that they're not open-coded because list.h implements doubly
linked lists, and extents use a singly linked list. That said, I suppose
we could make the extents doubly linked and use list.h, even though that
would be a waste of 4/8 bytes per extent.

> - if we don't agree on something, we ask someone wiser (volunteers welcome ;-))

Absolutely!

Thursday, April 05, 2007

Ada harapan baru winmodem bisa dipakai

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC883 Analog [ALC883 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]
Subdevices: 0/1
Subdevice #0: subdevice #0

$ sudo /etc/init.d/sl-modem-daemon start
Starting SmartLink Modem driver for: hw:0,6.
Creating /dev/modem symlink, pointing to: /dev/ttySL0.

$ sudo wvdialconf
Editing `/etc/wvdial.conf'.

Scanning your serial ports for a modem.

Modem Port Scan<*1>: S0 S1 S2 S3
WvModem<*1>: Cannot get information for serial port.
ttySL0<*1>: ATQ0 V1 E1 -- OK
ttySL0<*1>: ATQ0 V1 E1 Z -- OK
ttySL0<*1>: ATQ0 V1 E1 S0=0 -- OK
ttySL0<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK
ttySL0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK
ttySL0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK
ttySL0<*1>: Modem Identifier: ATI -- SmartLink Soft Modem
ttySL0<*1>: Speed 4800: AT -- OK
ttySL0<*1>: Speed 9600: AT -- OK
ttySL0<*1>: Speed 19200: AT -- OK
ttySL0<*1>: Speed 38400: AT -- OK
ttySL0<*1>: Speed 57600: AT -- OK
ttySL0<*1>: Speed 115200: AT -- OK
ttySL0<*1>: Speed 230400: AT -- OK
ttySL0<*1>: Speed 460800: AT -- OK
ttySL0<*1>: Max speed is 460800; that should be safe.
ttySL0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK

Found a modem on /dev/ttySL0.
Modem configuration written to /etc/wvdial.conf.
ttySL0: Speed 460800; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0"

Sunday, April 01, 2007

Code::Blocks for Debian

I wonder why nobody try to package Code::Blocks, a good, GUI, IDE into Debian. It was wnpp-ed long time ago (April 2005), then abandoned. The easy alternative is to use Ubuntu's which have been actively developed. Instaling them into Debian Sid was very smooth. But then I said to myself, "Why wouldn't I try compile it myself?". I tried, and it was a rather frustrating experience :(

My result so far: succes on Debian Etch AMD64. Big failure on Debian Sid i386. We need this tiny patch to compile it in Debian:

--- codeblocks/debian/rules.orig        2007-04-01 14:15:57 +0700
+++ codeblocks/debian/rules 2007-04-01 14:17:11 +0700
@@ -93,7 +93,7 @@
# dh_installemacsen
# dh_installpam
dh_installmime
- dh_iconcache
+# dh_iconcache
# dh_installinit
# dh_installcron
# dh_installinfo
In Sid i386, preparation process by running bootstrap always failed with this uncommunicative error messages:
src/base/tinyxml/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined
src/base/tinyxml/Makefile.am:6:
src/base/tinyxml/Makefile.am:6: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
src/base/tinyxml/Makefile.am:6: to `configure.in' and run `aclocal' and `autoconf' again.
So I tried alternative: run bootstrap on Ubuntu Dapper AMD64, apply above patch, then continue build fakeroot debian/rules binary. Voila! We got a native Debian one!

Update April 4th, 2007
I found the culprit: libtool from experimental. After downgrading back to sid, everything's fine now.