Request for Comments on proposed Tivo Hacking Framework

[BTUx9]

In the same vein as the enhancements script that zipper and sapper run, I'm proposing a new framework with some significant changes/improvements.

I've been running systems with most of these ideas (except the services, and only partial implementation of auto-hacking) for a couple years now, and it works rather well.

I'm separating my main topics into several different posts so they'll be easier to quote/thread.

[BTUx9]

Instead of the traditional use of /test.conf and /etc/rc.d/rc.sysinit.author, which is error-prone and often difficult to modify safely, I propose a set of 3 points where user hacks are introduced... pre, mid, post. (the mid hacks would be performed immediately before myworld, etc. are started up.)

The startup scripts would be similar to tivo's and linux's in that, rather than adding/deleting lines to a file like author, there'd be directories where scripts would be sourced in glob order.

A special form of the startup script name would be reserved for starting Services (see below)

[BTUx9]

Most linuxes have some sort of mechanism for managing services.

I believe a similar framework should be implemented on the tivo, storing those scripts in /usr/services, and using something along the lines of "service <name> (start|stop|restart)", where the service script would contain a number of helper functions to make the scripts for individual services easier to write and more consistent.

[BTUx9]

Localizing hacks to a single location (/usr, in this case) would give several advantages:

1) the contained files can be easily stored in root, var, or (optimally) a separate partition, with almost no modifications to the framework

2) easier backup/sync of a machine's hacks

3) by implementing most "hooks" into the existing tivo root using symlinks, makes automated hacking (see below) much easier

[BTUx9]

By using a chainload system, it should be possible to allow upgrades to proceed with little or no user intervention, and, upon detection, the new, virgin root would be hacked automatically (mostly through hooks to /usr).

This process would be very similar to the initial hack.