gldm_stop man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]

GLD(9E)								       GLD(9E)

       gld,	gldm_reset,    gldm_start,    gldm_stop,    gldm_set_mac_addr,
       gldm_set_multicast,   gldm_set_promiscuous,    gldm_send,    gldm_intr,
       gldm_get_stats, gldm_ioctl - Generic LAN Driver entry points

       #include <sys/gld.h>

       int prefix_reset(gld_mac_info_t *macinfo);

       int prefix_start(gld_mac_info_t *macinfo);

       int prefix_stop(gld_mac_info_t *

       int prefix_set_mac_addr(gld_mac_info_t *
	    macinfo, unsigned char *macaddr);

       int prefix_set_multicast(gld_mac_info_t *
	    macinfo, unsigned char *multicastaddr,
	    int multiflag);

       int prefix_set_promiscuous(gld_mac_info_t *macinfo,
	     int promiscflag);

       int prefix_send(gld_mac_info_t *macinfo,
	    mblk_t *mp);

       uint_t prefix_intr(gld_mac_info_t *macinfo);

       int prefix_get_stats(gld_mac_info_t *macinfo,
	    struct gld_stats *stats);

       int prefix_ioctl(gld_mac_info_t *macinfo,
	    queue_t *q, mblk_t *mp);

       Solaris architecture specific (Solaris DDI).

			 Pointer to a gld_mac_info(9S) structure.

			 Pointer  to  the  beginning of a character array con‐
			 taining a valid MAC address.  The array  will	be  of
			 the   length	specified   by	 the   driver  in  the
			 gldm_addrlen element of the  gld_mac_info(9S)	struc‐

			 Pointer  to  the  beginning of a character array con‐
			 taining a multicast, group,  or  functional  address.
			 The  array  will  be  of  the length specified by the
			 driver	  in   the   gldm_addrlen   element   of   the
			 gld_mac_info(9S) structure.

			 A  flag indicating whether reception of the multicast
			 address is to be enabled or disabled.	This  argument
			 is  specified	as  GLD_MULTI_ENABLE or GLD_MULTI_DIS‐

			 A flag indicating what type of promiscuous  mode,  if
			 any,  is to be enabled. This argument is specified as

			 Pointer  to  a	 STREAMS  message block containing the
			 packet to be transmitted or the ioctl to be executed.

			 Pointer to a gld_stats(9S) structure to be filled  in
			 with the current values of statistics counters.

			 reply to the ioctl.

       These entry points must be implemented  by  a  device-specific  network

       between	the  device-specific  driver  and  the	GLD  module   is   the
       function pointers to the entry points described here.  The  device-spe‐
       cific driver must, in its attach(9E) routine, initialize these function
       pointers before calling gld_register().

       gldm_reset() resets the hardware to its initial state.

       gldm_start() enables the device to generate interrupts and prepares the

       gldm_stop()  disables  the  device  from	 generating any interrupts and

       gldm_set_mac_addr() sets the physical address that the hardware	is  to
       passed MAC address macaddr.

       gldm_set_multicast() enables and	 disables  device-level	 reception  of
       specific multicast addresses. If the third argument multiflag is set to
       GLD_MULTI_ENABLE, then the function sets the interface to receive pack‐
       ets  with  the  multicast address pointed to by the second argument; if
       multiflag is set to GLD_MULTI_DISABLE, the driver is allowed to disable
       reception of the specified multicast address.

       This  function is called whenever GLD wants to enable or disable recep‐
       tion of a multicast, group, or functional address. GLD makes no assump‐
       tions  about how the device does multicast support and calls this func‐
       tion to enable or disable a specific multicast  address.	 Some  devices
       may  use a hash algorithm and a bitmask to enable collections of multi‐
       cast addresses; this is allowed, and GLD will filter out any  superflu‐
       ous packets that are not required. If disabling an address could result
       responsibility  of  the	device	driver to keep whatever information it
       needs to avoid disabling an address that GLD has enabled but  not  dis‐

       gldm_set_multicast()  will  not be called to enable a particular multi‐
       cast address that is already enabled, nor to disable an address that is
       not  currently  enabled.	 GLD  keeps track of multiple requests for the
       same multicast address and only calls the driver's entry point when the
       multicast address is made.

       gldm_set_promiscuous() enables  and  disables  promiscuous  mode.  This
       function	 is  called whenever GLD wants to enable or disable the recep‐
       tion of all packets on the medium, or  all  multicast  packets  on  the
       GLD_MAC_PROMISC_PHYS, then the function enables physical-level  promis‐
       cuous mode, resulting in the reception of all packets on the medium. If
       promiscflag is set to GLD_MAC_PROMISC_MULTI, then reception of all mul‐
       ticast	packets	  will	 be   enabled.	 If   promiscflag  is  set  to
       GLD_MAC_PROMISC_NONE, then promiscuous mode is disabled.

       devices	that  have  no	multicast-only	promiscuous  mode must set the
       device to physical promiscuous mode to ensure that all multicast	 pack‐
       ets  are	 received. In this case the routine should return GLD_SUCCESS.
       The GLD software will filter out any superfluous packets that  are  not

       For forward compatibility, gldm_set_promiscuous() routines should treat
       any  unrecognized  values  for  promiscflag   as	  though   they	  were

       gldm_send()  queues  a packet to the device for transmission. This rou‐
       tine is passed a STREAMS message containing the packet to be sent.  The
       message may comprise multiple message blocks, and the send routine must
       chain through all the message blocks  in	 the  message  to  access  the
       driver should check to ensure that the packet does not exceed the maxi‐
       mum allowable packet size, and must pad the packet,  if	necessary,  to
       the  minimum  allowable	packet	size. If the send routine successfully
       transmits or queues the packet, it should return GLD_SUCCESS.

       The send routine should return GLD_NORESOURCES if it cannot immediately
       inform GLD that it should retry	packets	 that  the  driver  previously
       again  returns  GLD_NORESOURCES	from its gldm_send() routine; however,

       If the driver's send routine returns GLD_SUCCESS, then  the  driver  is
       responsible for freeing the message when the driver and the hardware no
       case  the  driver  will probably free the message in the interrupt rou‐
       tine, or in a buffer-reclaim operation at the  beginning	 of  a	future
       send  operation.	 If  the  send	routine	 returns  anything  other than
       GLD_SUCCESS, then the driver must not free the message.

       is  possible  to	 share	interrupts with other devices, the driver must
       check the device status to determine  whether  it  actually  caused  an
       interrupt, then this routine must return DDI_INTR_UNCLAIMED.  Otherwise
       it  must	 service  the interrupt and should return DDI_INTR_CLAIMED. If
       the interrupt was caused by successful receipt of a packet,  this  rou‐
       tine  should  put  the  received	 packet into a STREAMS message of type
       M_DATA and pass that message to gld_recv().

       gld_recv() will pass the inbound packet	upstream  to  the  appropriate
       set the b_rptr and b_wptr members of the STREAMS message before calling


       The interrupt code should increment statistics counters for any errors.
       This includes failure to allocate a buffer needed for the received data

       gldm_get_stats()	 gathers  statistics  from  the hardware and/or driver
       stats. This routine is called by GLD when it gets a request for statis‐
       tics, and provides the mechanism by which GLD acquires device dependent
       statistics from the driver before composing its reply to the statistics
       statistics counters.

       gldm_ioctl()  implements	 any device-specific ioctl commands. This ele‐
       ment may be specified as NULL if the  driver  does  not	implement  any
       ioctl  functions.  The driver is responsible for converting the message
       before  returning  GLD_SUCCESS.	This  function	should	always	return
       GLD_SUCCESS; any errors	the  driver  may  wish	to  report  should  be
       returned	 via  the message passed to qreply(9F). If the gldm_ioctl ele‐
       ment is specified as NULL, GLD will return a message of	type  M_IOCNAK
       with an error of EINVAL.

       gldm_intr() must return:

			      if  and  only  if	 the  device definitely inter‐

			      if the device did not interrupt.

       The other functions must return:

			    on success. gldm_stop()  and  gldm_ioctl()	should
			    always return this value.

			    if	there  are insufficient resources to carry out
			    the	    request	at     this	time.	  Only
			    gldm_set_mac_addr(),	 gldm_set_multicast(),
			    gldm_set_promiscuous(), and gldm_send() may return
			    this value.

			    if gldm_send() is called when there is no physical
			    connection to a network or link partner.

			    if the requested function is not  supported.  Only
			    gldm_set_mac_addr(),   gldm_set_multicast(),   and
			    gldm_set_promiscuous() may return this value.

			    if the function detected an	 unsuitable  argument,
			    for	 example,  a  bad multicast address, a bad MAC
			    address, or a bad packet or packet length.

			    on hardware failure.

       attach(9E), ddi_add_intr(9F)

       Writing Device Drivers

				  Jan 3, 2001			       GLD(9E)

List of man pages available for SmartOS



Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net