Again, I can’t sleep yet and it’s 7.16 in the morning… my insomnia starts pissing me off. Unfortunately it’s not just insomnia: lately there has been a huge amount of burglar alarms going off during the morning. Seems like people forget to disable them before opening the door, with two unpleasant results: the first is that they easily wake up people with light sleep, the second is that we grow used to hearing the alarms going off, so the only time it is going off because of a burglar entry, nobody will ever think of calling the police. A couple of days ago, there has been an alarm going off and then shutting up repeatedly for about two hours… at the body shop near to my house they were probably trying a burglar alarm, but couldn’t they find a decent way to handle it?
Anyway, since I’m stuck at the MacBook Pro nowadays, and I can’t work on Gentoo, I decided to take a look to complete one of the tasks I had in my TODO list for a long time: fixing a few issues with libcdio and OSX. When I started working on unieject I originally hoped to get it to work not only on Linux and FreeBSD, but on as many operating systems as libcdio allowed. One of the operating system I was going to try with was supposed to be OSX, but when I started looking into it, I found a very bad implementation of it; the truth is that the OSX driver in libcdio is mostly an hack and I wouldn’t suggest anybody to use it seriously, for now.
In particular, the eject function ends up executing through popen a call to hdiutil, a tool similar to FreeBSD’s cdcontrol, that already implements the eject command. Not really nice, eh? (In particular, FreeBSD’s cdcontrol is quite interesting, the main issue I have with it is that the interface is far from being similar to Linux’s eject: unieject aims not to implement things that are totally missing, but to implement them with the same interface on every supported operating system).
Anyway, thanks to Matt Messier, the xine contributor working on Mac OS X porting, I finally have the code to replace that abomination: starting from Mac OS X 10.4 (Tiger), there is a new framework, DiskArbitation, that handles unmount and eject of devices (it was private in 10.3, but it’s public nowadays). Matt already implemented the autoconf check for the presence of the framework, so importing that code into libcdio was trivial (the license of the two libraries is the same, GPL2+, it’s also worth nothing that xine-lib already uses libcdio for some features like vcd handling, but let’s skip over that, I’ll talk about it another time).
The main issue with doing this was that I had to install MacPorts on the laptop, as I didn’t have anything installed before, now I’m installing some parts of my usual environment: I’ll be stuck on this laptop for another month most likely, I can’t leave myself to forget how to develop 😉 Unfortunately I don’t have much free space on the disk, I’ll either have to delete the Gentoo installation on it, or buy an external HDD to keep the photos my sister takes (she has a camera and a camcorder, both digital, but no computer).
There is another function that libcdio implements by calling an external program, and it’s the one to close the CD drive tray… unfortunately although I have a quite clean idea of what I should do to replace it, I can’t test it for sure as both the MacBook Pro and the iBook have slot-loading CD drives, the tray will never close 😉
I have to say, also, that libcdio would need a quite deep refactoring: there are functions wrapping MMC commands, functions wrapping partially MMC commands, functions that use the CdIo_t handle, and functions taking the path of the device to eject. Seems like functions were added when needed without caring too much for an interface. I know unieject also started this way, and I have in my TODO list to clean that up.
Talking about unieject, I’ll have to cleanup the partition unmount support for Linux, but to do that I’ll need Enterprise. The fact that you can change both the device name and the major/minor number assignment makes it impossible to find, just by the name of the device, the partitions that has to be unmounted. You can just hope that the device only contain one partition, but this is not always true when it comes down to USB mass storage devices.
The only way to actually get the information needed is to find the exact device in the /sys tree, and then analyse the children… in reality, the only way to handle this decently is to use HAL, as bad as that might sound for a simple utility as unieject. I think I might look into adding optional HAL support in the future.
For what concerns ZeroConf, after my rant about Knoppix not providing a stack, I’ve been thinking of how many ways ZeroConf can be used to make more transparent a network. The first thing that comes to my mind is the neat Bonjour support for CUPS that Apple developed and merged in CUPS codebase after acquiring it: I was at a support call last June, at a print shop where the network was totally fooled up (and technicians paid ten times I was paid weren’t able to fix it… it just needed a router!); after fixing the network, their main network printer changed IP address, rather than having one from the ISP’s MAN, it then had an internal local IP address. The two eMacs were still able to access the printer through AppleTalk, while Windows had to be reconfigured almost from scratch, there was no easy way to just tell it to change the IP address the printer was present at. Discoverable printers are a godsend sometimes.
Other uses that might be useful for local networks are of course the ability to see which boxes are up and running and providing SSH, SFTP, FTP or other services: opening iTerm from here tells me I have a box that allows all three of them: the AppleTV. I wonder if a feature like that is implemented in Konsole 4, I’d certainly make use of it. Then there is the ability to see the network shares: it would be cool to just boot a system, maybe even a LiveCD, and find on the desktop not only the local partitions to be accessed.. but also all the network shares for the fileserver.
Now, of course there are already methods to do this without going the MDNS/Bonjour/Avahi route: CUPS uses IPP and SLP discovery, Samba implements some features of the SMB protocol that allows discoverable shares, you can use SLP to broadcast presence of services, too. There was even an article on the GWN (if I recall correctly, but I’m sure I’ve seen one somewhere) on how to set up a discoverable rsync server for the local network by using SLP. But why should we have three different discovery methods (four if we count SSDP used by UPnP)?
It would be also a nice way to handle a trusted network segment where nodes are connected either for building (distcc) or for in-memory storage of temporary or cached data (memcache). Just think about a distcc that automatically finds the boxes that support the current architecture: you wouldn’t have to change configuration if you add, remove, shutdown or power on a new box…
An interesting exercise for someone who would like to experiment would be to rewrite the tutorial for discoverable rsync servers to use Avahi rather than OpenSLP; I have to reiterate I can’t do it as I’m stuck without Enterprise, and thus unable to do any Gentoo-related work, till about mid-september, when I will be able to buy the new hard disks.
