Re: [PATCH] fix 32 bit compilation on MinGW-w64
Go ahead On 29.12.2013 11:10, Andrey Borzenkov wrote: > Use _FILE_OFFSET_BITS macro to distinguish between native MinGW and > 32 bit under MinGW-64. The latter does not require fseeko/ftello > redefinition which it already does in case of _FILE_OFFSET_BITS=64. > > --- > include/grub/osdep/hostfile_windows.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/grub/osdep/hostfile_windows.h > b/include/grub/osdep/hostfile_windows.h > index 36615b2..79efcfa 100644 > --- a/include/grub/osdep/hostfile_windows.h > +++ b/include/grub/osdep/hostfile_windows.h > @@ -69,8 +69,11 @@ enum grub_util_fd_open_flags_t > > #if defined (__MINGW32__) && !defined (__MINGW64__) > > +/* 32 bit on MinGW-64 already redefines them if _FILE_OFFSET_BITS=64 */ > +#if !defined(_FILE_OFFSET_BITS) > #define fseeko fseeko64 > #define ftello ftello64 > +#endif > > #endif > > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add apple_set_os command
On 30.12.2013 17:04, Andreas Heider wrote:
> +static const grub_efi_char8_t apple_os_version[] = "Mac OS X 10.9";
> +static const grub_efi_char8_t apple_os_vendor[] = "Apple Inc.";
> +
Can those be optionally supplied on command line?
E.g.
apple_set_os [[VENDOR] VERSION]
On the other hand we should probably start collecting whitelist of macs
who need this and do it on them automatically. Idk if there is EFI
variable to identify mac model from EFI but it's possible from SMBIOS.
> +static grub_err_t
> +grub_cmd_apple_set_os (grub_command_t cmd __attribute__ ((unused)),
> + int argc __attribute__ ((unused)),
> + char **args __attribute__ ((unused)))
> +{
> + grub_efi_guid_t apple_set_os_guid = GRUB_EFI_APPLE_SET_OS_PROTOCOL_GUID;
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add apple_set_os command
В Вт, 07/01/2014 в 14:38 +0100, Vladimir 'φ-coder/phcoder' Serbinenko пишет: > On 30.12.2013 17:04, Andreas Heider wrote: > > +static const grub_efi_char8_t apple_os_version[] = "Mac OS X 10.9"; > > +static const grub_efi_char8_t apple_os_vendor[] = "Apple Inc."; > > + > Can those be optionally supplied on command line? > E.g. > apple_set_os [[VENDOR] VERSION] > On the other hand we should probably start collecting whitelist of macs > who need this and do it on them automatically. Idk if there is EFI > variable to identify mac model from EFI but it's possible from SMBIOS. I wonder what became of smbios command. Would be good to have generic way to fetch it. signature.asc Description: This is a digitally signed message part ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add apple_set_os command
Am 2014-01-07 14:38, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
On 30.12.2013 17:04, Andreas Heider wrote:
+static const grub_efi_char8_t apple_os_version[] = "Mac OS X 10.9";
+static const grub_efi_char8_t apple_os_vendor[] = "Apple Inc.";
+
Can those be optionally supplied on command line?
E.g.
apple_set_os [[VENDOR] VERSION]
On the other hand we should probably start collecting whitelist of macs
who need this and do it on them automatically. Idk if there is EFI
variable to identify mac model from EFI but it's possible from SMBIOS.
I'll try to find the time to implement the command line arguments
tonight, and I am pretty sure that there is a way to get the model from
EFI. I just hope that Apple implemented this correctly.
One thing I'm still wondering about is how this could integrate better
with EFISTUB. Do you know how for example the broadcom fix is applied in
that scenario? Is the same fix just duplicated in the Linux kernel?
Because if we implement a whitelist in grub and then suddenly Linux boot
properly with grub but not directly with EFISTUB things become quite
ugly.
+static grub_err_t
+grub_cmd_apple_set_os (grub_command_t cmd __attribute__ ((unused)),
+ int argc __attribute__ ((unused)),
+ char **args __attribute__ ((unused)))
+{
+ grub_efi_guid_t apple_set_os_guid =
GRUB_EFI_APPLE_SET_OS_PROTOCOL_GUID;
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add apple_set_os command
Am 2014-01-03 19:38, schrieb SevenBits: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2014 01:46 AM, Vladimir '?-coder/phcoder' Serbinenko wrote: On 31.12.2013 00:11, SevenBits wrote: On Monday, December 30, 2013, Andreas Heider wrote: The EFI on current macbooks configures hardware differently depending on wether it is booting Mac OS X or a different os, for example disabling the internal GPU completely on some models. Mac OS X identifies itself using a custom EFI protocol. This adds a command that fakes the os identification, making all hardware accessible. Just a question: I do a lot of booting Linux on MacBooks, and I frequently suffer from this issue. How do we know that this code actually works? Run on a mac with this code and without and compare results. The ship of "works by sane design" has long since sailed away. For most manufacturers it's somewhere in Moon orbit but for apple it has long since left solar system. So, Andreas, I tried your patch, and... no dice. The Mac behaves exactly as before. I'm afraid it didn't appear to do anything for me. Hi, thanks for testing! I suspect that your MacBook Pro is simply too old. I don't know exactly when this protocol was introduced, I found references to it on Hackintosh-Forums from a while ago and in the Mac OS X internals book which is also a bit older. What effect exactly were you looking for? Your MBP doesn't have a second GPU to disable. Also, AFAIK the older models disable less hardware when you boot via EFI than the newer ones, since Bootcamp with EFI wasn't supported. Furthermore, your patch didn't print any output. There wasn't any error message returned (i.e your "Could not locate the apple set os protocol." message on line 52-53). When I invoked your command from the GRUB normal prompt, it DID print the message however. Perhaps it doesn't fail if called from within a grub.cfg, or maybe it simply doesn't print. If it prints something on the promt I'd say it's working as intended, although I'm pretty sure that I see output from it when I boot a grub.cfg entry. The Mac that I tested on was a MacBook Pro from early 2008. Clearly, this function isn't present on all models. I can try it on others and seeing if it works on them, however. If you have the time, please do. I'd be interested in what exactly changes. Also, why the if statements on lines 59 and 65, which indicate whether the OS version and/or vendor was set. What is the point of them? Why not just call the functions directly? It's just some output so you know that the command did something. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSxwOMAAoJEFbRvtGxmFPELWoH+QGu7aLuDam0vY+xW8h4TdFw ckY51K8vgEGlpUNvK2fwQnnAt57W3jH14HBIRY1IaC+c9XA3mooqp748xh0jfoV/ D95lZJuYu3XP4iFYtCehcCVOiz+x4DNXMnT6WA6hd5FjPT9xqbBqf/9RxSpN9O+i ZGbSe/ZQkOvTyLXJ11L3SeTlNi9jqA03mLaMrMi7Ehb7AU3hBkiSMpiiIcUjnP3o ZskQrSkguqt9Kt+FlHheTJkpAitqqJR/GpHkegg3bNGLrflacVGITMFFw0EsJP4R h0fsEocfYnvSVPrw07SJVFvt2TzPGB69p5QXy11cU1ZBYUhILcG7rDTAmVctZig= =wKye -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[patch] arm64: set correct length of device path end entry
The length of the Device Path End entry in the grub_linux_boot() funtcion is incorrectly set to 0. This triggers an assert failure in debug builds of Tianocore. The correct length is 4 bytes (1 byte type, 1 byte subtype, 2 bytes length). Reported-by: Mark Salter diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c index 9d15aad..7c9bc2b 100644 --- a/grub-core/loader/arm64/linux.c +++ b/grub-core/loader/arm64/linux.c @@ -268,7 +268,7 @@ grub_linux_boot (void) mempath[1].header.type = GRUB_EFI_END_DEVICE_PATH_TYPE; mempath[1].header.subtype = GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE; - mempath[1].header.length = 0; + mempath[1].header.length = 4; b = grub_efi_system_table->boot_services; status = b->load_image (0, grub_efi_image_handle, ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] arm64: set correct length of device path end entry
Go ahead. On 07.01.2014 18:06, Leif Lindholm wrote: > The length of the Device Path End entry in the grub_linux_boot() > funtcion is incorrectly set to 0. This triggers an assert failure > in debug builds of Tianocore. > > The correct length is 4 bytes (1 byte type, 1 byte subtype, > 2 bytes length). > > Reported-by: Mark Salter > > diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c > index 9d15aad..7c9bc2b 100644 > --- a/grub-core/loader/arm64/linux.c > +++ b/grub-core/loader/arm64/linux.c > @@ -268,7 +268,7 @@ grub_linux_boot (void) > >mempath[1].header.type = GRUB_EFI_END_DEVICE_PATH_TYPE; >mempath[1].header.subtype = GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE; > - mempath[1].header.length = 0; > + mempath[1].header.length = 4; > >b = grub_efi_system_table->boot_services; >status = b->load_image (0, grub_efi_image_handle, > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [patch] arm64: set correct length of device path end entry
On 07.01.2014 18:06, Leif Lindholm wrote: > The length of the Device Path End entry in the grub_linux_boot() > funtcion is incorrectly set to 0. This triggers an assert failure > in debug builds of Tianocore. > > The correct length is 4 bytes (1 byte type, 1 byte subtype, > 2 bytes length). > > Reported-by: Mark Salter > > diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c > index 9d15aad..7c9bc2b 100644 > --- a/grub-core/loader/arm64/linux.c > +++ b/grub-core/loader/arm64/linux.c > @@ -268,7 +268,7 @@ grub_linux_boot (void) > >mempath[1].header.type = GRUB_EFI_END_DEVICE_PATH_TYPE; >mempath[1].header.subtype = GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE; > - mempath[1].header.length = 0; > + mempath[1].header.length = 4; > Could you use sizeof ? >b = grub_efi_system_table->boot_services; >status = b->load_image (0, grub_efi_image_handle, > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: booting btrfs
On Jan 1, 2014, at 10:17 PM, Michael Chang wrote: > > We snapshot /boot for kernel and initrd, otherwise the rollback would > encounter problem of incompatible userland and kernel/kernel modules. > And we need the ability to rollback them in terms of usefulness. Of course, understood. core.img is only going to point to one /boot, which may not be the /boot snapshot needed for the kernel and initrd. This will be really confusing for mortal users. They'd be unlikely to figure it out and understand it, without documentation. If core.img points to the "current" /boot, which it should, that boot has the accumulated knowledge of all snapshots, and any recently updated grub modules. Choosing to boot a snapshot means using a different /boot for kernel/initramfs than what grub is using for its root. I don't off hand see a problem with this because it's literally just two files that grub loads from a different boot subvolume, found with an absolute path to that snapshot. And it also uses rootflags=subvol= to use the matching root snapshot. A separate issue that's not grub's problem is how to deal with the (now wrong) fstab entries. systemd looks at fstab and generates mount jobs from that; if taught to understand it's booting a snapshot it could second guess parts of the fstab. Based on the name of the currently booting root snapshot, which systemd definitely knows, it could mount that subvol= instead of what's in fstab. It can use name substitution to do the same thing with the other subvolume-snapshots that match the root one. Meaning all of the snapshots for a system have the same base (re)naming convention. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Skip Apple ghosts
В Вт, 24/12/2013 в 14:26 +0100, Vladimir 'φ-coder/phcoder' Serbinenko пишет: > Hello, all. It was discovered that on macs sometimes firmware defines > ghost disks with vendor suffix. E.g. > /ACPI(a0341d0,0)/PCI(2,1f)/UnknownMessaging(12)/EndEntire > is a normal disks with partitions presented with HD(...) but then > /ACPI(a0341d0,0)/PCI(2,1f)/UnknownMessaging(12)/MediaVendor(Apple)[0: > ]/EndEntire > is a ghost disk. It has as suffix a vendor path with empty vendor data. > This is a problem because when chainloading on such disks GRUB can't > find handle of partition as none is defined. I propose to dkip ghosts > completely. This should be safe as the skip happens only for empty Apple > vendor suffix and if the parent is already a known disk. > Did anyone see anything similar? Yes (on MacBook Pro); Here is what I get when EFI-booting from GRUB rescue CD made with single x86_64-efi target: /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/EndEntire disk block /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/MediaVendor(2b0585eb-d8b8-49a9-8b8c-e21b01aef2b7)[0: ]/EndEntire block simple FS /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/HD(2,10,5c1,,20,0)/EndEntire disk block /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/HD(3,5d1,ca3,,20,0)/EndEntire simple FS disk block /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/HD(4,1274,a2,,20,0)/EndEntire disk block The three HD media paths are for three Apple partitions (and the third one has simple FS because it does contains HFS+). And I /think/ that the very first Vendor media path refers to CD-ROM (based on the fact that it got simple FS protocol). I played a bit with it; when I try to list filesystem for this media path in EFI shell, it audibly tries to access CD-ROM but fails. May be it requires Apple ISO9660 extensions, but I do not know how to create EFI bootable image containing Apple extensions (mkisofs should support it, but I was lost in arguments. xorriso apparently does not support Apple extensions). In your case you have SATA DVD drive, right? And path shown refers to it? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Skip Apple ghosts
В Вт, 24/12/2013 в 14:26 +0100, Vladimir 'φ-coder/phcoder' Serbinenko пишет: > Hello, all. It was discovered that on macs sometimes firmware defines > ghost disks with vendor suffix. E.g. > /ACPI(a0341d0,0)/PCI(2,1f)/UnknownMessaging(12)/EndEntire > is a normal disks with partitions presented with HD(...) but then > /ACPI(a0341d0,0)/PCI(2,1f)/UnknownMessaging(12)/MediaVendor(Apple)[0: > ]/EndEntire > is a ghost disk. It has as suffix a vendor path with empty vendor data. > This is a problem because when chainloading on such disks GRUB can't > find handle of partition as none is defined. I propose to dkip ghosts > completely. This should be safe as the skip happens only for empty Apple > vendor suffix and if the parent is already a known disk. > Did anyone see anything similar? Yes (on MacBook Pro); Here is what I get when EFI-booting from GRUB rescue CD made with single x86_64-efi target: /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/EndEntire disk block /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/MediaVendor(2b0585eb-d8b8-49a9-8b8c-e21b01aef2b7)[0: ]/EndEntire block simple FS /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/HD(2,10,5c1,,20,0)/EndEntire disk block /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/HD(3,5d1,ca3,,20,0)/EndEntire simple FS disk block /ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/HD(4,1274,a2,,20,0)/EndEntire disk block The three HD media paths are for three Apple partitions (and the third one has simple FS because it does contains HFS+). And I /think/ that the very first Vendor media path refers to CD-ROM (based on the fact that it got simple FS protocol). I played a bit with it; when I try to list filesystem for this media path in EFI shell, it audibly tries to access CD-ROM but fails. May be it requires Apple ISO9660 extensions, but I do not know how to create EFI bootable image containing Apple extensions (mkisofs should support it, but I was lost in arguments. xorriso apparently does not support Apple extensions). In your case you have SATA DVD drive, right? And path shown refers to it? signature.asc Description: This is a digitally signed message part ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] add part_apple to EFI rescue image to fix missing prefix
On Mac rescue image is booted from HFS+ partition, so bootpath looks like
/ACPI(a0341d0,0)/PCI(1,1f)/ATAPI(0,0,0)/HD(3,5d1,ca3,,20,0)/EndEntire
grub fails to find device for this path because it cannot scan partition
table. The simplest fix is to add part_apple by default.
---
util/grub-mkrescue.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/util/grub-mkrescue.c b/util/grub-mkrescue.c
index 0d03e55..30bb701 100644
--- a/util/grub-mkrescue.c
+++ b/util/grub-mkrescue.c
@@ -316,9 +316,11 @@ make_image_fwdisk_abs (enum grub_install_plat plat,
fclose (load_cfg_f);
grub_install_push_module ("iso9660");
+ grub_install_push_module ("part_apple");
grub_install_make_image_wrap (source_dirs[plat], "()/boot/grub", output,
0, load_cfg, mkimage_target, 0);
grub_install_pop_module ();
+ grub_install_pop_module ();
}
static int
--
tg: (e7cfa8d..) u/apple-boot-path (depends on: master)
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Add apple_set_os command
On Jan 7, 2014, at 10:19 AM, andr...@heider.io wrote: > Am 2014-01-03 19:38, schrieb SevenBits: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> On 01/03/2014 01:46 AM, Vladimir '?-coder/phcoder' Serbinenko wrote: >>> On 31.12.2013 00:11, SevenBits wrote: On Monday, December 30, 2013, Andreas Heider wrote: The EFI on current macbooks configures hardware differently depending on wether it is booting Mac OS X or a different os, for example disabling the internal GPU completely on some models. Mac OS X identifies itself using a custom EFI protocol. This adds a command that fakes the os identification, making all hardware accessible. Just a question: I do a lot of booting Linux on MacBooks, and I frequently suffer from this issue. How do we know that this code actually works? >>> Run on a mac with this code and without and compare results. The >>> ship of "works by sane design" has long since sailed away. For >>> most manufacturers it's somewhere in Moon orbit but for apple it >>> has long since left solar system. >> So, Andreas, I tried your patch, and... no dice. The Mac behaves >> exactly as before. I'm afraid it didn't appear to do anything for me. > > Hi, > thanks for testing! I suspect that your MacBook Pro is simply too old. I > don't know exactly when this protocol was introduced, I found references to > it on Hackintosh-Forums from a while ago and in the Mac OS X internals book > which is also a bit older. > > What effect exactly were you looking for? Your MBP doesn't have a second GPU > to disable. > Also, AFAIK the older models disable less hardware when you boot via EFI than > the newer ones, since Bootcamp with EFI wasn't supported. I was looking for any change in the video behavior. You are correct that my MBP does not have a second GPU, but I was looking for any change at all that might indicate the patch worked. Anyway, the patch didn’t work on my machine, so I guess the point is moot. > >> Furthermore, your patch didn't print any output. There wasn't any >> error message returned (i.e your "Could not locate the apple set os >> protocol." message on line 52-53). When I invoked your command from >> the GRUB normal prompt, it DID print the message however. Perhaps it >> doesn't fail if called from within a grub.cfg, or maybe it simply >> doesn't print. > > If it prints something on the promt I'd say it's working as intended, > although I'm pretty sure that I see output from it when I boot a grub.cfg > entry. > >> The Mac that I tested on was a MacBook Pro from early 2008. Clearly, >> this function isn't present on all models. I can try it on others and >> seeing if it works on them, however. > > If you have the time, please do. I'd be interested in what exactly changes. Perhaps it would be a good way to see which MBPs have this protocol as well. > >> Also, why the if statements on lines 59 and 65, which indicate whether >> the OS version and/or vendor was set. What is the point of them? Why >> not just call the functions directly? > > It's just some output so you know that the command did something. > >>> ___ Grub-devel mailing >>> list Grub-devel@gnu.org >>> https://lists.gnu.org/mailman/listinfo/grub-devel >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.14 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> iQEcBAEBAgAGBQJSxwOMAAoJEFbRvtGxmFPELWoH+QGu7aLuDam0vY+xW8h4TdFw >> ckY51K8vgEGlpUNvK2fwQnnAt57W3jH14HBIRY1IaC+c9XA3mooqp748xh0jfoV/ >> D95lZJuYu3XP4iFYtCehcCVOiz+x4DNXMnT6WA6hd5FjPT9xqbBqf/9RxSpN9O+i >> ZGbSe/ZQkOvTyLXJ11L3SeTlNi9jqA03mLaMrMi7Ehb7AU3hBkiSMpiiIcUjnP3o >> ZskQrSkguqt9Kt+FlHheTJkpAitqqJR/GpHkegg3bNGLrflacVGITMFFw0EsJP4R >> h0fsEocfYnvSVPrw07SJVFvt2TzPGB69p5QXy11cU1ZBYUhILcG7rDTAmVctZig= >> =wKye >> -END PGP SIGNATURE- >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: Message signed with OpenPGP using GPGMail ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
