Files
libguestfs/generator
Richard W.M. Jones e3ebd50abd New API: guestfs_device_name returning the drive name
For each drive added, return the name.  For example calling this with
index 0 will return the string "/dev/sda".  I called it
guestfs_device_name (not drive_name) for consistency with the existing
guestfs_device_index function.

You don't really need to call this function.  You can follow the
advice here:
https://libguestfs.org/guestfs.3.html#block-device-naming
and assume that drives are added with predictable names like
"/dev/sda", "/dev/sdb", etc.

However it's useful to expose the internal guestfs_int_drive_name
function since especially handling names beyond index 26 is tricky
(https://rwmj.wordpress.com/2011/01/09/how-are-linux-drives-named-beyond-drive-26-devsdz/)

Fixes: https://github.com/libguestfs/libguestfs/issues/80
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit ac00e603f8)
2022-07-06 17:17:56 +01:00
..
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-09-21 18:56:18 +01:00
2019-09-10 17:52:16 +02:00
2020-03-06 19:32:32 +00:00
2021-04-08 11:12:17 +01:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-06-04 13:49:35 +01:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2021-12-09 13:46:28 +00:00
2020-03-06 19:32:32 +00:00
2021-09-23 14:52:46 +01:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2021-03-05 13:22:05 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2019-07-29 10:28:31 +01:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2021-04-03 12:02:35 +01:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2021-11-09 10:21:30 +00:00
2017-01-29 17:32:22 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00
2020-03-06 19:32:32 +00:00

This program generates a large amount of code and documentation for
all the daemon actions.

To add a new action there are only two files you need to change,
'actions_*.ml' to describe the interface, and daemon/<somefile>.c to
write the implementation.

After editing these files, build it (make -C generator) to regenerate
all the output files.  'make' will rerun this automatically when
necessary.

IMPORTANT: This program should NOT print any warnings at compile time
or run time.  If it prints warnings, you should treat them as errors.

OCaml tips:

(1) In emacs, install tuareg-mode to display and format OCaml code
correctly.  'vim' comes with a good OCaml editing mode by default.

(2) Read the resources at http://ocaml.org/learn/

(3) A module called 'Foo' is defined in one or two files called
'foo.mli' and 'foo.ml' (NB: lowercase first letter).  The *.mli file,
if present, defines the public interface for the module.  The *.ml
file is the implementation.  If the *.mli file is missing then
everything is exported.

Some notable files in this directory:

  actions_*.ml        The libguestfs API.
  proc_nr.ml          Procedure numbers associated with each API.
  structs.ml          Structures returned by the API.
  c.ml                Generate C API.
  <lang>.ml           Generate bindings for <lang>.
  main.ml             The main generator program.

Note about long descriptions:

When referring to another action, use the format C<guestfs_other>
(ie. the full name of the C function).  This will be replaced as
appropriate in other language bindings.  Apart from that, long
descriptions are just perldoc paragraphs.

Note about extending functions:

In general you cannot change the name, number of required arguments or
type of required arguments of a function, since this would break
backwards compatibility.

You may add another optional argument, *if* the function has >= 1
optional arguments already.  Add it at the end of the list.

You may add optional arguments to a function that doesn't have any.
However you *must* set the once_had_no_optargs flag to true, so that
the relevant backwards compatibility bindings can be added.