Drivers

[KostyaEsmukov]

Intention of this issue is to come up with established terminology and design on such a complex part of the LR.

I will update this post in the course of discussion.

Terms:

• mountpoint - linux mount point (see mount(8))
• driver (module) - a module to create a mountpoint on a board using FUSE
• mountpoint path - a root path for all driver mountpoints on a board (../drivers - consider making it configurable. Also I would prefer it to be /mnt/lr_drivers.)
• endpoint - a path within a mountpoint. Like a file or a directory.
• driver name - a unique identifier of a driver on a board.
• driver sourcecode - a javascript code of a driver module. (TODO, see below)
• global drivers config - a json file, containing driver states of all drivers. (./drivers.json)
• driver state - an object, representing driver state

{ driverName?: string, status: 'injected' | 'mounted' | 'unmounted', remote: boolean, autostart: boolean, mirrorBoard: string }

• driver path - a root directory of a driver module, where its sourcecode and config are located. (./drivers)
• driver config - TODO, see below
• mirror board - a board code of a board, running the same driver module, to use that driver module operations instead of a local one.

[KostyaEsmukov]

Design issues (from my point of view):

driver sourcecode

Variable read/write function names are very confusing and error-prone. I propose to implement its interface this way:

interface DriverModule {
  init(cb: (result: {result: 'SUCCESS' | 'ERROR', message: string}) => void);
  finalize(cb: (result: {result: 'SUCCESS' | 'ERROR', message: string}) => void);
  getEndpointStrategy(name: string): DriverModuleEndpointOperations;  // name is that variability of read/write functions. 
}

interface DriverModuleEndpointStrategy {
  open(cb: () => void, endpoint: string);
  read(cb: (readContent: Buffer) => void, endpoint: string);
  write(buf: Buffer, cb: () => void, endpoint: string);
}

or, much better, with promises:

interface DriverModule {
  init(): Promise<void>;
  finalize(): Promise<void>;
  getEndpointStrategy(name: string): DriverModuleEndpointOperations;  // name is that variability of read/write functions. 
}

interface DriverModuleEndpointStrategy {
  open(endpoint: string): Promise<void>;
  read(endpoint: string): Promise<Buffer>;
  write(buf: Buffer, endpoint: string): Promise<void>;
}

driver config

Currently it's a

{
  name: string,  // driver name. what for?
  type: string,  // tend to be file/dir, but actually unused
  permissions: string, // of root endpoint, 600, 777, etc.
  children: {
    name: string,  // it's a path, actually
    read_function: string, 
    write_function: string, 
    permissions: string
  }[]
}

It's too excessive. I propose:

{
  rootPermissions: string, // of root endpoint, 600, 777, etc.
  endpoints: {
    path: string,
    endpointStrategy: string,
    permissions: string
  }[]
}

remote

I explained that part in the email. In short - I would like to get a gist of how can a local module be used along with remote one.