On Thu, 31 Oct 2013 09:14:47 +0200 Ayman Hendawy ayman.hendawy@gmail.com wrote:
Dear Neil,
Do not reply to individuals. Keep replies only to the list.
Actually I wonder why it's not more open, why I can't get a real time access to the kit serial console, why debugger is not available, suppose I have an application over OS, I need to debug my code using a debugger, to get know the certain line causing the problem, why I don't have an access to some of the kit peripherals like USB port by some how.
What I mean, such great effort of LAVA, what limit it to give there users more deeply access to there kits? why it's limited to posting jobs?
The simple answer is that this is to protect the use of the boards by other users. Submitting a job puts the device into a test image where the bugs in the test image are restricted to that test image. When the test ends (for better or for worse), the board returns to a known, working, state.
To do otherwise would make the admin burden unsustainable.
These are not general purpose debugging boards. These are test devices. The hands-on debugging needs to be done in emulators or local boards - preferably before the commits. LAVA is checking for side-effects of developer changes, especially performance changes over time.
Access to the serial console of any LAVA device is restricted to the lab admins. The devices do not belong to the developers, it isn't about developers having access to "their" devices. The devices belong to LAVA and are maintained as a service for all developers. Doing that requires that LAVA imposes restrictions on what individual developers can do to avoid individuals leaving the device in an unstable or unbootable state.
Many LAVA test jobs involve interim kernel builds - it is all too easy to make a commit which gets turned into a LAVA job which leads to a kernel panic in the test. If that was the main kernel for the device, *someone* (i.e. the LAVA lab admins) would have to fix it. Restricting tests to submitted jobs is that fix.